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Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

IP Multimedia (IM) Core Network (CN) subsystem Service Continuity (SC) provides the capability of continuing 
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The present document provides the protocol details for enabling IMS SC based on the Session Initiation protocol (SIP) 
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MAP, ISUP, BICC and the NAS call control protocol for the CS access). 

The present document is applicable to User Equipment (UEs), Apphcation Servers (AS), MSC Servers providing IMS 
Service Continuity capabilities. Emergency Access Transfer Function (EATF), Access Transfer Control Function 
(ATCF). 
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[64] 



3GPP TS 24.337 "IP Multimedia (IM) Core Network (CN) subsystem; inter-UE transfer; Stage 3". 



3 



Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
3GPPTR 21.905 [1]. 

Dynamic STI: An STl dynamically assigned by the SCC AS, representing the SIP dialog identifier (Call-ID header 
field and the values of tags in To and From header fields) and used for session transfer request when Gm service control 
is available. 

Additional transferred session SCC AS URI: A SIP URI which is a public service identity hosted by SCC AS and 
which is used during PS-CS access transfer with the MSC Server assisted mid-call feature. 

Static STI: An STI configured in the SC UE either as a SIP URI or as an E.164 number in tel URI or SIP URI 
representation of tel URI. The static STI is used for CS-PS transfer when dynamic STI is vmavailable. 

Active audio media: SDP media component of audio media type which has "recvonly" or "sendrecv" directionality at 
the SC UE or at the MSC server serving the SC UE. 

Inactive audio media: SDP media component of audio media type which has "sendonly" or "inactive" directionality at 

the SC UE or at the MSC server serving the SC UE. 

ATCF URI for originating requests: A URI of ATCF where the ATCF receives requests sent by the served UEs. 
ATCF URI for terminating requests: A URI of ATCF where the ATCF receives requests targeted to the served UEs. 
For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [9] apply: 
Access Leg 

Access Transfer Control Function (ATCF) 
Access Transfer Gateway (ATGW) 

Access Transfer Update - Session Transfer Identifier (ATU-STI) 
Local Operating Environment 
Remote Leg 
Target Access Leg 
Source Access Leg 

Emergency Session Transfer Number for SR VCC (E-STN-SR) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.292 [4] apply: 



For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [12] apply: 

Correlation MSISDN 

IP Multimedia Routeing Number (IMRN) 

Session Transfer Identifier (STI) 

Session Transfer Number (STN) 

Session Transfer Number for SR-VCC (STN-SR) 

For the purposes of the present document, the following terms and definitions given in IETF RFC 5012 [16] apply: 
Emergency service URN 



CS call 
CS media 
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For the purposes of the present document, the following terms and definitions given in IETF RFC 4353 [55] apply: 

Conference 
Conference URI 
Focus 
Participant 

For the purposes of the present document, the following terms and definitions given in IETF RFC 3264 [58] apply: 
Directionality 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [xx] apply: 
ICS user 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 



EATF 


Emergency Access Transfer Function 


E-STN-SR 


Emergency Call Session Transfer Number - Single Radio 


E-SR-VCC 


Emergency Single Radio Voice Call Continuity 


C-MSISDN 


Correlation MSISDN 


IMRN 


IP Multimedia Routing Number 


sc 


Service Continuity 


sec 


Service Centralization and Continuity 


SM 


Session Management 


SR-VCC 


Single Radio VCC 


STI 


Session Transfer Identifier 


STN 


Session Transfer Number 


STN-SR 


Session Transfer Number - Single Radio 



4 Overview of IP IVIultimedia (IIVI) Core Network (CN) 
subsystem Service Continuity 

4.1 General 

In general, IMS Service Continuity provides the capabiUty of continuing ongoing communication sessions with multiple 

media across different access networks. The main need for such continuity arises because user equipments (UEs) with 
multimedia capabilities can move across a multiplicity of different access networks. 

NOTE: The capability of continuing ongoing communication sessions as a collaboration between different user 
equipments (UEs) is described in 3GPP TS 24.337 [64]. 

The following procedures are provided within this document: 

- procedures for registration in IM CN subsystem are specified in clause 6; 

- procedures for call origination are specified in clause 7; 

- procedures for call termination are specified in clause 8; 

- procedures for PS-CS access transfer are specified in clause 9; 

- procedures for PS-PS access transfer are specified in clause 10; 
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- procedures for PS-PS access transfer in conjunction with PS-CS access transferare specified in clause 1 1 ; 

- procedures for PS-CS access transfer for Single Radio are specified in clause 12; 

- procedures for media adding/deleting for access transfer are specified in clause 13; 

- procedures for service continuity and MMTEL interactions are specified in clause 20. 

For a UE or an AS not supporting ICS procedures, PS-CS access transfer procedures enable transfer of 
one active full-duplex speech or speech/video session; and 

- up to one active and up to one inactive active full-duplex speech or speech/video session when the MSC Server 
assisted mid-call feature is supported. 

4.2 Underlying network capabilities 

SC assumes the use of a number of underlying network capabilities: 

1) provision by the home network operator of SCC AS on the IM CN subsystem, as specified in 
3GPPTS 24.229 [2]; 

2) if ICS is used, the network capabihties as specified in 3GPP TS 24.292 [4]; 

4.3 URI and address assignments 

In order to support SC to a subscriber, the following URI and address assignments are assumed: 

a) in this version of the document, the SC UE for access transfer will be configured with a static STI, in accordance 
with subclause 5.1 1 in 3GPP TS 24.216 [5]; a static STN in accordance with subclause 5.12 in 

3GPP TS 24.216 [5]. The static STI is used by the SC UE to perform CS to PS access transfer when no 
dynamically assigned STI is provided to the UE over the CS domain (e.g. when the SC UE does not support ICS 
capabihties as defined in 3GPP TS 24.292 [4]). The static STN is used by the SC UE to perform PS to CS access 
transfer when no service control signalling path as specified in 3GPP TS 24.292 [4] is available. 

b) the SC UE wiU be configured to be reachable in both the IM CN subsystem and the CS domain by one or more 
public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. 
Either: 

- this public telecommunication number can be the DN (e.g. MSISDN) used in the CS domain and (in 
international form) comprise part of the implicit registration set associated with that SC UE in the IM CN 
subsystem; or 

the SCC AS can be configured to provide a functional relationship between separate numbers providing each 
of these identities in the CS domain and the IM CN subsystem, respectively. 



5 Functional entities 

5.1 Introduction 

This clause associates the functional entities with the SC roles described in the stage 2 architecture document (see 
3GPPTS 23.237 [9]). 

5.2 User Equipment (UE) 

To be compliant with access transfer in this document, a UE shall implement the role of an SC UE according to 
subclause 6A,2, subclause 6.2, subclause 7.2, subclause 8.2, subclause 9.2, subclause 10.2, subclause 11.2, 
subclause 12.2, subclause 13.2 and subclause 20.1. 
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5.3 Application Server (AS) 

To be compliant with access transfer in this document, an AS shall implement the role of an SCC AS according to 
subclause 6.3, subclause 7.3, subclause 8.3, subclause 9.3, subclause 10.3, subclause 11.3, subclause 12.3, 
subclause 13.3 and subclause 20.1. 

5.4 IVISC server 

An MSC server can be compliant with SRVCC session transfer procedures as described in this document. 

In order to be compUant with SRVCC session transfer procedures as described in this document: 

an MSC server using SIP interface to initiate the session transfer shall provide the UA role as defined for a 
MGCF in annex A of 3GPP TS 24.229 [1 1] and the role of an MSC server enhanced for SRVCC using SIP 
interface as described in subclause 12.6; or 

an MSC server shall provide the role of an MSC server enhanced for ICS as specified in subclause 12.4. 1 

An MSC server can be compliant with the access transfer procedures for the MSC server assisted mid-call feature as 
described in this document. 

In order to be compliant with the access transfer procedures for the MSC server assisted mid-call feature as described in 
this document, the MSC server shall: 

- provide the role of an MSC server enhanced for ICS as described in subclause 6.4, subclause 9.4 and 
subclause 12.4; or 

- provide the role of an MSC server enhanced for SRVCC using a SIP interface as described in subclause 12.6.1. 

In order to enable the UE to remove/add participants from/to an IMS conference call after the access transfer, the MSC 
Server supporting the MSC server assisted mid-caU feature shall provide the role of an MSC server enhanced for ICS. 

5.5 EATF 

To be compliant with access transfer in this document, the EATF shall act as B2BUA and: 

- extract charging information as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.1.2; 

- identify the served user as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.1.3A.2; 

- map the message header fields from a SIP message received in one dialog to related SIP message sent in the 
correlated dialog managed by EATF as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 

- pass signalling elements as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 

- handle P-Charging- Vector header as specified for an routeing AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; and 

- implement the role of an EATF according to subclause 7.4 and subclause 12.5. 

5.6 Access Transfer Control Function (ATCF) 

To be compliant with access transfer in this document, the ACTF shall: 

1) provide the proxy role as defined in 3GPP TS 24.229 [2], with the exceptions and additional capabihties as 
described for the ATCF in subclause 6.5, subclause 6A.3, subclause 7.5, subclause 8.4, and subclause 12.7; 

2) provide the B2BUA functionality with the exceptions and additional capabilities as described for the ATCF in 
subclause 12.7. When providing the B2BUA functionality, the ATCF shall provide the UA role as defined in 
3GPP TS 24.229 [2] and additionaUy shaU: 

A. map the message header fields from a SIP message received in one dialog to related SIP message sent in the 
correlated dialog managed by ATCF as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 
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B. pass signalling elements as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; and 

C. transparendy forward received Contact header field; and 

3) if decided to anchor the media in ATGW according to operator policy: 

NOTE: At this point, ATCF interacts with ATGW to provide information needed in subsequent bullets. The 
details of interaction between ATCF and ATGW are out of scope of this document. 

A. upon receiving an SDP included in a SIP message sent by the served UE within the dialog, replace the SDP 
in the received SIP message with updated SDP provided by ATGW; and 

B. upon receiving an SDP included in a SIP message sent by remote UE within the dialog, replace the SDP in 
the received SIP message with updated SDP provided by ATGW. 

Editor's note: it is to be checked with SA5 if there any charging related requirements in ATCF 

6 Roles for registration in the IIVI CN subsystem for 
service continuity 

6.1 Introduction 

Void. 

6.2 SC UE 

Prior to performing IMS registration, if the SC UE supports ICS capabilities as defined in 3GPP TS 24.292 [4], the SC 
UE shall check that IMS service continuity using ICS is enabled. An indication that SC using ICS is enabled or disabled 
can be found in the ICS MO ICS_Capabihties_Enabled leaf node (see 3GPP TS 24.286 [23]). 

The SC UE shall follow the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN 
subsystem. 

If SC using ICS is enabled then prior to making use of ICS procedures, the SC UE shall follow the procedures specified 
in 3GPP TS 24.292 [4] for registration of the ICS UE in the IM CN subsystem. 

If the SC UE not supporting ICS or with ICS capabilities disabled, and supports the multiple registrations as defined in 
3GPP TS 24.229 [2] then the SC UE shall include the g.3gpp.accesstype media feature tag as described in subclause B.3 
of 3GPP TS 24.292 [4] in the Contact header field of the SIP REGISTER request. 

6.3 sec AS 
6.3.1 General 

The sec AS can obtain registration state information that it needs to implement SCC specific requirements from: 

a) any received third-party SIP REGISTER request (e.g. including information contained in the body of the third- 
party SIP REGISTER request) as specified in 3GPP TS 24.229 [2]; 

b) any received reg event package as specified in 3GPP TS 24.229 [2]; or 

c) the Sh interface as specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7]. 

NOTE: Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know 
the capabilities supported by the user registered UE(s), including the used IP-CAN(s). 
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When the SCC AS obtains the registration state information including an Correlation MSISDN using one of the above 
procedures, the SCC AS shall determine if the registration state information is associated with ongoing CS call by 
matching the Correlation MSISDN against the: 

a) tel URI in the P-Asserted-Identity header field or associated with the received IMRN when the SIP INVITE 
request was due to static STN, where the SIP INVITE request was stored according to subclause 7.3.1; or 

b) tel URI in the Request-URI when the SIP INVITE request was due to processing unregistered filter criteria, 
where the SIP INVITE request was stored according to subclause 7.3.1. 

If the registration state information is associated with an ongoing call the contents of the registration state information 
shall be bound to the ongoing CS call session identifier. 

6.3.2 Triggers for the SCC AS providing information to ATCF 

The remaining part of this subclause applies for a contact address (or a registration flow, if multiple registration 
mechanism is used) in the registration state information obtained by SCC AS, which: 

1) is registered by UE: 

A) in E-UTRAN, UTRAN and GERAN access networks; and 

NOTE: The access network where the UE performed registration can be found in the P-Access-Network-Info 
header field of the SIP REGISTER request. 

B) for a private user identity associated with a C-MSISDN; and 

2) is associated with a Path header field with the g.3gpp.atcf media feature tag. 

The SCC AS shall identify the related ATCF as the URI in the Path header field with the g.3gpp.atcf media feature tag 
associated with such contact address (or such registration flow, if multiple registration mechanism is used). 

The SCC AS shall determine that SRVCC is usable for the UE if the UE SRVCC Capability (see 3GPP TS 29.328 [6]) 
of the UE has value UE-SRVCC-CAP ABILITY-SUPPORTED and if the private user identity of the UE has associated 
STN-SR (see 3GPP TS 29.328 [6]). 

When the SCC AS becomes aware of new such contact address (or new such registration flow, if multiple registration 
mechanism is used) and SRVCC is usable for the UE, the SCC AS shall provide the SRVCC related information to the 
related ATCF as described in subclause 6.3.3. 

When the SCC AS becomes aware that UE which registered such contact address (or such registration flow, if multiple 
registration mechanism is used): 

- and SRVCC was usable for the UE and SRVCC is not usable for the UE now; or 

- and SRVCC was not usable for the UE and SRVCC is usable for the UE now; 

then the SCC AS shall provide the SRVCC related information to the related ATCF as described in subclause 6.3.3. 

6.3.3 SCC AS providing tlie SRVCC related information to tlie ATCF 

In order to provide the SRVCC related information to the ATCF, the SCC AS shall perform the role of AS acting as 
originating UA according to 3GPP TS 24.229 [2] subclause 6.7.3 and shall send a SIP MESSAGE request populated as 
follows: 

1) Request-URI set to the URI of the ATCF associated with the registration (or registration flow, if multiple 
registration mechanism is used); 

NOTE: The URI of the ATCF can be found in the Path header field with the g.3gpp.atcf media feature tag in the 
SIP REGISTER request which the S-CSCF received from the UE using method a) as described in 
subclause 6.3.1. 

2) P-Asserted-ldentity header field containing the identity of the SCC AS; and 

3) the application/vnd.3gpp.SRVCC-info+xml MIME body as defined in annex D. 
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6.4 MSG server 

If the MSC server: 

provides the role of an MSC server enhanced for ICS; 

supports the MSC server assisted mid-call feature; and 

determines that the served user is an ICS user; 

then in addition to the procedures specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] the MSC server shall 
include the g.3gpp. mid-call media feature tag (as described in annex C) in the Contact header field of the SIP 
REGISTER request. 

6.5 Access Transfer Control Function (ATCF) 

6.5.1 Distinction of requests 

The ATCF needs to distinguish the following initial SIP requests: 

1) SIP REGISTER requests with the ATCF URI for originating requests in the topmost Route header field. In the 
procedures below, such requests are known as "SIP REGISTER requests of served UE". 

2) SIP MESSAGE requests with the ATCF URI for terminating requests in the Request-URI and 

A. not containing Route header field; or 

B. containing URI in the topmost Route header field other than the ATCF URI for originating requests and other 
than the ATCF URI for terminating requests. 

In the procedures below, such requests are known as "SIP MESSAGE requests with the SRVCC related 
information". 

6.5.2 Registation related procedures in the ATCF 

Upon receiving a SIP REGISTER request of served UE, the ATCF shall: 

1. if ATCF decides to include itself for access transfer of sessions according to operator policy: 
A. insert a Path header field with: 

a. the ATCF URI for terminating requests containing public service identity constructed such that the 
registration can be determined from the user portion of the ATCF URI for terminating requests; and 

Editor's note [eSRVCC, CR#0417]: it is FFS whether the ATCF URI for terminating requests and the public service 
identity where SRVCC infomation are sent can be the same URI or whether two different URIs can be 
provided 

NOTE 1 : one possible construction method is to set the user portion of the ATCF URI for terminating requests to 
the URI of the most bottom Path header field of the SIP REGISTER request. 

b. the g.Bgpp.atcf media feature tag containing the STN-SR allocated to ATCF as described in IETF draft- 
holmberg-sipcore-proxy-feature [60] . 

Upon receiving a SIP 2xx response to the SIP REGISTER request of served UE and if ATCF decided to include itself 
for access transfer of sessions according to operator policy, the ATCF shall update the S-CSCF Service-Route URI 
bound to the registration (see subclause 6A.3.1) identified by the P-CSCF Path URI. 

NOTE 2: The P-CSCF Path URI is the URI in the most bottom Path header field of the SIP 2xx response to the SIP 
REGISTER request. 

NOTE 3: The S-CSCF Service-Route URI is the URI in the most bottom Service-Route header field of the SIP 2xx 
response to the SIP REGISTER request. 
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6.5.3 ATCF receiving tine SRVCC related information 

Upon receiving SIP MESSAGE request with the SRVCC related information, the ATCF shall: 

1) if the URI in the P-Asserted-Identity header field of the SIP MESSAGE request does not identify an SCC AS 
authorized to provide the SRVCC related information, reject the request with SIP 403 (Forbidden) response and 
do not continue with the remaining steps; and 

NOTE: in this version of specification, the URIs of SCC ASs authorized to provide SRVCC information need to 
be specified in the roaming agreement. 

2) update the SRVCC information bound to the registration(s) (see subclause 6A.3.1) with information in the 
application/vnd.3gpp.SRVCC-info+xml MIME body of the SIP MESSAGE request. 



6A Roles for General Capabilities 
6A.1 Introduction 

This clause describes the general roles for each functional entity as specified. 

6A.2 UE roles 

The SC UE may receive the operator policy via OMA Device Management, see 3GPP TS 24.216 [5]. When the SC UE 
receives the operator pohcy, for each session to be transferred, it shall take the operator policy into account when 
deciding to perform the following: 

selecting the access for initiating the transfer; 

- determining whether to transfer full or partial media during PS-PS transfer; or 

- determining whether to add or remove media during the PS-PS transfer. 

If the SC UE is configured with the operator policy (e.g. via OMA Device Management as described in 

3GPP TS 24.216 [5J) then, for each media or group of media contained in the MediaorGroup node, the SC UE shall: 

1) restrict originating sessions and session transfer towards the access networks contained in the 
RestrictedAccessNetworkType node; 

2) consider the list of access networks contained in the PreferredAccessNetworks node in the order of priority from 
the access networks such that, when available, the highest priority access network can be used for originating 
sessions and session transfer procedures; 

3) if a new access network gets available- transfer media components to a higher priority target network than the 
current access network based on the value contained in the SC_media_transfer node value. If the 
SC_media_transfer node value is: 

"shall" the UE shall start a session transfer according to the home operator' s hst of preferred access networks 
contained in the PreferredAccessNetworks node; 

"should" the UE is recommended to start session transfer according to the home operator' s list of preferred 
access networks contained in the PreferredAccessNetworks node. The UE can evaluate if session transfer is 
possible and desirable after having taken into account the Local Operating Environment Information; and 

"may" the UE can decide whether or not to start session transfer in accordance with user preferences if 
configured in the UE. The UE can evaluate if session transfer is possible and desirable after having taken into 
account the Local Operating Environment Information. If user preferences are not configured, the UE can 
evaluate the home operator' s list of preferred access networks contained in the PreferredAccessNetworks 
node; and 

4) decide whether to keep or drop non transferable media components in the case of partial session transfer based 
on the SC_non_transferrable_media node value. 
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6A.3 ATCF 

6A.3.1 SRVCC information bound to tlie registration 

The ATCF shall keep track of existing registrations of the served UEs. Each registration is identified by the P-CSCF 
Path URI. 

The ATCF shall bind the following information to the registration: 

- the S-CSCF Service-Route URI; 

- the ATU-STI; and 

- the C-MSISDN. 

When a registration of a served UE expires or is deregistered, the ATCF can remove any SRVCC information bound to 
the registration. 



7 Roles for call origination for service continuity 

7.1 Introduction 

This clause specifies the procedures for call origination, both where the SC UE is generating calls in the CS domain and 
where the SC UE is generating calls using the IM CN subsystem. Procedures are specified for the SC UE, the SCC AS 
and the EATF. 

7.2 SC UE 

7.2.1 General 

The SC UE shall support origination of IP multimedia sessions in the IM CN subsystem as specified in 
3GPP TS 24.229 [2]. If the SC UE supports the MSC server assisted mid-call feature, the SC UE shall include the 
g.Bgpp.mid-call media feature tag as described in annex C in the Contact header field of the SIP INVITE request. If the 
SC UE supports single radio PS to CS access transfer for calls in alerting state, the SC UE shall include the 
g.3gpp.srvcc-alerting media feature tag as described in annex C in the Contact header field of the SIP INVITE request. 

The SC UE shall support origination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

If SC using ICS is enabled then the procedures for call origination where the SC UE is initiating calls using CS media 
are identical to that for ICS UE specified in 3GPP TS 24.292 [4]. 

When originating an emergency call as specified in 3GPP TS 24.229 [2] and if the SC UE has an IMEI, then the SC UE 
shall include the instance-id media feature tag as specified in IETF RFC 5626 [22] with value based on the IMEI as 
defined in 3GPP TS 23.003 [12] in the Contact header field of the SIP INVITE request. 

7.2.2 Additional procedures with MSC server assisted mid-call feature 

Upon receiving a SIP 2xx response to the SIP INVITE request, if: 

1 . the SC UE supports the MSC server assisted mid-call feature; 

2. the g.3gpp. mid-call media feature tag is included in the Contact header field received during session 
establishment; 

3. the remote UE is a conference focus; and 

NOTE: conference focus includes the isfocus media feature tag specified in IETF RFC 3840 [53] in own Contact 
header field when establishing a session. 
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4. the session was created as result of the SC UE creating a conference; 

then the SC UE shall subscribe to the conference event package as specified in 3GPP TS 24.605 [31] and shall populate 
the Contact header field of the SUBSCRIBE request with the g.3gpp. mid-call media feature tag. 

If the subscription is accepted then the SC UE shall keep one subscription to the conference event package with own 
Contact header field containing the g.3gpp.mid-call media feature tag for each conference where the SC UE participates 
using procedures specified in 3GPP TS 24.605 [31]. 

7.3 sec AS 

7.3.1 Distinction of requests sent to tlie SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionaUty 
relating to call origination: 

- SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the origination procedures as specified in 3GPP TS 24.229 [2J, and therefore distinguished 
by the URl relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to originating filter criteria". It is 
assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from 
theUE. 

The SCC AS shall store the SIP INVITE requests due to static STN (as defined in subclause 9.3.1) and the SIP INVITE 
requests due to originating filter criteria, at least until their sessions are terminated. 

The SCC AS needs to distinguish between the following initial requests to provide specific functionality related to 
obtaining conference participants: 

- SIP SUBSCRIBE requests with an Event header field containing "conference" and with the Contact header field 
containing the g.3gpp.mid-call media feature tag routed to the SCC AS over the ISC interface as a result of 
processing initial filter criteria at the S-CSCF according to the originating procedures as specified in 

3GPP TS 24.229 [2]. In the procedures below, such requests are known as "SIP SUBSCRIBE requests to 
conference event package". 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

7.3.2 Call origination procedures at the SCC AS 

When the SCC AS receives a SIP INVITE request due to originating filter criteria, the SCC AS shall follow the SCC 
AS roles for call origination procedures specified in 3GPP TS 24.292 [4J. 

If: 

1. the SCC AS supports the MSC Server assisted mid-call feature according to operator poUcy; 

2. the g.3gpp. mid-call media feature tag as described in annex C is included in the Contact header field of the SIP 
INVITE request due to originating filter criteria; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

NOTE: SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id header 
field and the P- Access-Network-Info header field of the SIP REGISTER request. 

then the SCC AS shall include the g.3gpp.mid-call media feature tag as described in annex C in the Contact header field 
of the SIP 2xx response to the SIP INVITE request due to originating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the g.3gpp.mid-call media feature tag as described in annex C from the SIP INVITE request due to originating 
filter criteria before forwarding the SIP INVITE request towards the remote UE. 
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If: 

1. the sec AS supports SRVCC for calls in alerting phase according to operator policy; 

2. the g.3gpp.srvcc-alerting media feature tag as described in annex C is included in the Contact header field of the 
SIP INVITE request due to originating filter criteria; and 

3. the sec AS is aware that all MSC servers in the network where the UE is registered which can be involved in 
SRVCC procedures support the SRVCC for calls in alerting phase; 

NOTE: The SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id 
header field and the P- Access-Network-Info header field of the SIP REGISTER request. 

then the SCC AS shall include the g.Sgpp.srvcc-alerting media feature tag as described in annex C in the Record-Route 
header field of any SIP Ixx or 2xx response to the SIP INVITE request due to originating filter criteria as described in 
IETF draft-holmberg-sipcore-proxy-feature [60]. 

If the SCC AS supports the SRVCC for calls in alerting phase according to operator policy, the SCC AS shall remove 
the g.3gpp.srvcc-alerting media feature tag as described in annex C from the SIP INVITE request due to originating 
filter criteria before forwarding the SIP INVITE request towards the remote UE. 

7.3.3 Subscription related procedures in tlie SCC AS 

When the SCC AS receives a SIP SUBSCRIBE request to conference event package, if the SCC AS supports the MSC 
Server assisted mid-call feature according to operator policy and if SCC AS determines that the subscription is related 
to an anchored session then the SCC AS shall ensure that it remains on the path for future requests in the dialog before 
forwarding the request. 

NOTE: ASs acting as Routeing B2BUA and record-routing ASs acting as SIP proxy remain on the path for future 
requests in the dialog. 

When the SCC AS receives SIP 2xx response to the SIP NOTIFY request with conference information, the SCC AS 
shall update the stored conference information based on the SIP NOTIFY request content and forward the SIP 2xx 
response in any manner conformant with 3GPP TS 24.229 [2]. 

The SCC AS shall determine that a subscription to conference event package is related to a session if: 

1 . the session was originated by served SC UE; 

2. remote UE of the session is a conference focus; 

3. the P-Asserted-Identity header field of the served SC UE used at the estabhshment of the session is the same as 
the P-Asserted-Identity header field of the served SC UE used at the subscription; and 

4. the Contact or the P-Asserted-ldentity header field provided to the served SC UE at the establishment of the 
session is the same as the Request-URI used at the subscription; 

If multiple such subscriptions exist, the SCC AS shall select the subscription that originates from the same device as the 
session. 

7.4 EATF 

7.4.1 Distinction of requests sent to tine EATF 

The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionahty 
relating to call origination: 

- SIP INVITE request including a request URl that contains an emergency service URN, i.e. a service URN with a 
top-level service type of "sos" as specified in IETF RFC 5031 [17]. In the procedures below, such requests are 
known as "SIP INVITE requests due to emergency service URN". 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 
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7.4.2 Call origination procedures at the EATF 

When the EATF receives a SIP INVITE requests due to emergency service URN, the EATF shall store the SIP INVITE 
request until the session is terminated, anchor the session and act as specified for a routeing B2BUA in 
3GPP TS 24.229 [2], subclause 5.7.5.2.1. 

7.5 Access Transfer Control Function (ATCF) 

7.5.1 Distinction of requests 

The ATCF needs to distinguish the following initial SIP requests: 

- SIP INVITE requests with the ATCF URI for originating requests in the topmost Route header field. In the 
procedures below, such requests are known as "originating SIP INVITE requests". 

7.5.2 Call origination procedures in the ATCF 

Upon receiving the originating SIP INVITE request, the ATCF shall: 

NOTE 1: Since the ATCF acts as proxy, the dialog identifier of the SIP INVITE request is not modified by 
procedures of the subclause. 

1) if the latest SRVCC related information (as defined in subclause 6A.3.1) received for the IMS registration with 
the S-CSCF Service-Route URI matching the URI in the most bottom Route header field of the originating SIP 
INVITE request contain ATU-STI and C-MSISDN: 

A) associate the session being established with the C-MSISDN and the ATU-STI bound to the registration (see 
subclause 6A.3.1) with the S-CSCF Service-Route URI matching the URI in the most bottom Route header 
field of the originating SIP INVITE request; and 

B) if the originating SIP INVITE request contains SDP offer and if decided to anchor the media according to 
operator policy as specified in 3GPP TS 23.237 [9], replace the SDP offer in the originating SIP INVITE 
request with updated SDP provided by ATGW; 

NOTE 2: ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

before forwarding the request. 



8 Roles for call termination for service continuity 

8.1 Introduction 

This clause specifies the procedures for call termination, both where the SC UE is receiving calls in the CS domain and 
where the SC UE is receiving calls using the IM CN subsystem Procedures are specified for the SC UE and the 
sec AS. 

8.2 SC UE 

The SC UE shall support termination of multimedia sessions in the IM CN subsystem as specified in 
3GPP TS 24.229 [2] with the following clarifications: 

1) If the SC UE supports the MSC server assisted mid-call feature, and the receiving SIP INVITE request includes 
g.3gpp. mid-call media feature tag as described in annex C in the Contact header field, the SC UE shall include 
the g.3gpp.mid-call media feature tag as described in annex C in the Contact header field of the SIP 2xx response 
to the SIP INVITE request. 
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la) If the SC UE supports single radio PS to CS access transfer for calls in alerting state, and the receiving SIP 
INVITE request includes g.3gpp.srvcc-alerting feature tag as described in annex C in the Contact header field, 
the SC UE shall include the g.3gpp.srvcc-alerting media feature tag as described in annex C in the Contact 
header field of the SIP 180 (Ringing) response to the SIP INVITE request. 

2) If the SC UE not supporting ICS or supporting ICS but with ICS Capabilities disabled receives a SIP INVITE 
request containing a SDP offer which includes audio media with speech codecs transported using an IP bearer, 
and: 

NOTE: An indication that an SC UE with ICS capabilities has its ICS capabilities enabled or disabled can be 
found in the ICS MO ICS_CapabiUties_Enabled leaf node (see 3GPP TS 24.286 [23]). 

a) if the SC UE sends the response to the SIP INVITE request over GERAN; 

b) if the SC UE sends the response to the SIP INVITE request over E-UTRAN or UTRAN, and the IMSVoPS 
indicator indicates that voice is not supported; or 

c) if the SC UE sends the response to the SIP INVITE request over an access network other than E-UTRAN, 
UTRAN and GERAN, and the access network does not support the offered audio media with speech codecs 
transported using an IP bearer; 

then the SC UE shall send back a SIP 488 (Not Acceptable Here) response without a message body 

The SC UE not supporting ICS or with ICS capabiUties disabled shall support termination of calls in the CS domain as 
specified in 3GPP TS 24.008 [8]. 

An SC UE that supports ICS and has ICS capabilities enabled shall follow the call termination procedures as specified 
in3GPPTS24.292[4]. 

When the SC UE not supporting ICS or with ICS capabilities disabled, and supports multiple registrations receives a 
SIP INVITE request containing SDP for establishing a session using just an IP bearer, then the SC UE shall estabUsh 
this session in accordance with 3GPP TS 24.229 [2] with the following clarification: 

- if the SIP INVITE request contains a Target-Dialog header field containing dialog parameters that correspond to 
an existing dialog (or a dialog in the process of being established) between the SC UE and SCC AS the SC UE 
shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog identified by 
the dialog parameters contained in the Target-Dialog header field; and 

- if the SIP INVITE request does not contain a Target-Dialog header field but there is an existing dialog (or a 
dialog in the process of being established) between the SC UE and SCC AS the SCC AS shall check if the dialog 
parameters for this request correspond to the dialog parameters received in a Target-Dialog header field received 
on an existing dialog (or a dialog in the process of being established) between the SC UE and SCC AS and if so 
then the SC UE shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog 
that the Target-Dialog header field was received on. 

NOTE: The second case is to cover the possibility that requests can arrive out of the order that they were sent. 

8.3 SCC AS 

8.3.1 Distinction of requests sent to tlie SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call termination: 

- SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the termination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header field. In the 
procedures below, such requests are known as "SIP INVITE requests due to terminating filter criteria". It is 
assumed that the SCC AS is the last AS that the S-CSCF forwards the request to. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 
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8.3.2 Call termination procedures in the SCC AS 

When the SCC AS receives a SIP INVITE request due to terminating filter criteria, the SCC AS shall follow the SCC 
AS roles for call termination procedures specified in 3GPP TS 24.292 [4]. 

If: 

1. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

2. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

then the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field 
of the SIP INVITE request due to terminating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the g.3gpp. mid-call media feature tag as described in annex C from the SIP 2xx response to the SIP INVITE 
request due to terminating filter criteria before forwarding the SIP 2xx response towards the remote UE. 

If: 

1 . the SCC AS supports SRVCC for calls in alerting phase according to operator policy; and 

2. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support SRVCC for calls in alerting phase; 

then the SCC AS shall include the g.Bgpp.srvcc-alerting media feature tag as described in annex C in the Record-Route 
header field of the SIP INVITE request due to terminating filter criteria as described in IETF draft-holmberg-sipcore- 
proxy-feature [60]. 

If the SCC AS supports SRVCC for calls in alerting phase according to operator policy, the SCC AS shall remove the 
g.3gpp.srvcc-alerting media feature tag as described in annex C from SIP Ixx and 2xx responses to the SIP INVITE 
request due to terminating filter criteria before forwarding the SIP Ixx and 2xx responses towards the remote UE. 

8.4 Access Transfer Control Function (ATCF) 

8.4.1 Distinction of requests 

The ATCF needs to distinguish the following initial SIP requests: 

SIP INVITE requests with the ATCF URI for terminating requests in the topmost Route header field. In the 
procedures below, such requests are known as "terminating SIP INVITE requests". 

8.4.2 Call termination procedures in the ATCF 

Upon receiving the terminating SIP INVITE request, the ATCF shall: 

NOTE 1: Since the ATCF acts as proxy, the dialog identifier of the SIP INVITE request is not modified by 
procedures of the subclause. 

1) if the latest SRVCC related information (as defined in subclause 6A.3.1) received for the IMS registration with 
the P-CSCF Path URI matching the URI in the most bottom Route header field of the originating SIP INVITE 
request contain ATU-STI and C-MSISDN: 

A) associate the session being established with the C-MSISDN and the ATU-STI bound to the registration (see 
subclause 6A.3.1) with the P-CSCF Path URI matching the URI in the most bottom Route header field of the 
terminating SIP INVITE request; and 

B) if the terminating SIP INVITE request contains SDP offer and if decided to anchor the media according to 
operator policy as specified in 3GPP TS 23.237 [9], replace the SDP offer in the originating SIP INVITE 
request with updated SDP provided by ATGW; 
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NOTE 2: ATCF interacts with ATGW to provide the needed media related information. The details of interaction 
between ATCF and ATGW are out of scope of this document. 

before forwarding the request. 



9 Roles for PS-CS access transfer 
9.1 Introduction 

For a UE or an AS not supporting ICS procedures, PS-CS access transfer procedures enable transfer of 
one active full-duplex speech or speech/video session; and 

- up to one active and up to one inactive active full-duplex speech or speech/video session when the MSC Server 
assisted mid-call feature is supported. 

9.1 A Additional procedures with IVISC Server assisted mid-call 

feature 

When a conference is transferred to CS domain using MSC Server assisted mid-call feature, the participants are 
extracted from the stored conference information as follows: 

1 . at maximum first 5 participants listed in the <user> elements: 

a. included in <users> parent element included in <conference-info> root element of the conference 
information; 

b. containing at least one <endpoint> child element with <status> child element containing one of the states 
"connected", "on-hold", "muted-via-focus", "pending", "alerting", "dialing-in" or "dialing-out"; and 

c where "entity" attribute is different than the URI in the P-Asserted-Identity header field of the served SC UE 
used at the subscription. 

9.2 SC UE 

9.2.1 SC UE procedures for PS to CS access transfer 

If SC UE uses ICS capabilities, this subclause applies for IMS sessions containing speech media component only, 
otherwise subclause 11.2.1.2 applies. 

The SC UE may be engaged in one or more ongoing sessions at the time of initiating access transfer. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initiiil SIP INVITE request to establish this session 
has been sent or received. 

If SC using ICS is enabled then if the SC UE is using Gm, then for each session to be transferred and starting with the 
active session, the SC UE shall send a SIP INVITE request to the SCC AS according to the ICS UE using Gm 
procedures for call origination as specified in 3GPP TS 24.292 [4]. The SC UE shall populate the SIP INVITE request 
as specified for PS-PS access transfer with full media transfer in subclause 10.2.1 (including the STl of the dialog to be 
transferred) with the following exceptions: 

- The SC UE shall indicate in the SIP INVITE request that the speech media is using CS bearer with its 
corresponding media description. 

Upon receiving the PSl DN from the SCC AS, the SC UE shall follow the procedures for call origination for ICS 
UE using Gm in 3GPP TS 24.292 [4] to set up the CS bearer. 
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If the SC UE is not using ICS capabilities and if the SC UE does not apply the MSC Server assisted mid-call feature as 
specified in subclause 9.2.1 A, subject to the SC_non_transferrable_media node value in the Communication Continuity 
MO (see subclause 5.27 in 3GPP TS 24.216 [5]), the SC UE shall: 

a) if more than one full-duplex speech session exists, first initiate the release of all the ongoing fuU-duplex speech 
sessions except the session with active full-duplex speech component that was most recently made active and 
then the SC UE shall transfer the remaining ongoing active full-duplex speech session. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send, a CC SETUP message as specified 
in 3GPP TS 24.008 [8], to the SCC AS to set up a call over the CS domain. When sending CC SETUP message, the SC 
UE shall populate the CC SETUP message as follows: 

1) the called party BCD number information element set to the static STN; and 

2) Type Of Number set to "International" and Numbering Plan Indicator set to "E.164".in the Called Party BCD 
Number information element. 

If the SC UE receives a release message to the CC SETUP message sent, then PS-CS access transfer has not completed 
successfully and the call will continue in the Source Access Leg. 

9.2.1 A SC UE procedures for PS to CS access transfer with MSC server 
assisted mid-call feature 

The SC UE shall apply the MSC Server assisted mid-call feature when transferring the session not using ICS 
capabilities if: 

1 . the SC UE supports the MSC Server assisted mid-call feature; and 

2. one of the following is true: 

A. there is at least one ongoing active full-duplex speech session and the Contact header field received during 
the establishment of the ongoing active fuU-duplex speech session which has been most recently made active 
includes the g.3gpp.mid-call media feature tag as described in annex C; or 

B. there is no ongoing active full-duplex speech session and the Contact header field received during the 
establishment of the ongoing inactive full-duplex speech session which became inactive most recently 
includes the g.3gpp.mid-call media feature tag as described in annex C. 

When the SC UE applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.2.1, and before sending a message to set up a call over the CS domain, the SC UE shall: 

1. if there are two or more ongoing active full-duplex speech sessions: 

A. initiate the release of all the ongoing full-duplex speech sessions except two that were most recently made 
active; 

B. initiate the session modification of the ongoing full-duplex speech session that was made active less recently 
and offer the full-duplex speech component with "sendonly" or "inactive" directionality; and 

C. transfer two remaining ongoing full-duplex speech sessions; 

NOTE 1: When active and inactive ongoing fuU-duplex speech sessions exist, one CC SETUP message transfers 
both sessions. 

2. if there are one ongoing active full-duplex speech session and one or more ongoing inactive full-duplex speech 
session, 

A. initiate the release of all the ongoing inactive full-duplex speech sessions except the one which became 
inactive most recently; and 

B. transfer two remaining ongoing full-duplex speech sessions; 

NOTE 2: When active and inactive ongoing full-duplex speech sessions exist, one CC SETUP message transfers 
both sessions. 
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3. if there is one ongoing active full-duplex speech session and no ongoing inactive full-duplex speech session, 
transfer the ongoing full-duplex speech session; and 

4. if there is no ongoing active full-duplex speech session and there is one or more ongoing inactive full-duplex 
speech sessions: 

A. initiate the release of all the ongoing inactive full-duplex speech sessions except the one which became 
inactive most recently; and 

C. transfer the ongoing full-duplex speech session. 

NOTE 3: The ongoing inactive full-duplex speech sessions is transferred to a held CS call. 

The SC UE shall associate the additional transferred session with CS call with transaction identifier calculated as in the 
table 9.2.1A-1 and TI flag value as in mobile originated call. 

Table 9.2.1 A-1 : held session transaction identifier calculation formula 



<transaction identifier of the additional transferred session> = (1 + <transaction identifier 
of the CS call established by the SETUP message>) modulo 7 



If: 

1. the SC UE has a subscription as described in subclause 7.2.2 for the active full-duplex speech session; or 

2. the active full-duplex speech session does not exist and the SC UE has a subscription as described in 
subclause 7.2.2 for the inactive full-duplex speech session; 

then the SC UE shall associate the participants extracted in subclause 9.1 A with transaction identifiers calculated as in 
the table 9.2.1A-2 and with TI flag of the session. The offsets 0, 2, 3, 4, 5 are assigned to the participants in their order 
in the list of the extracted participants. 

Table 9.2.1 A-2: transaction identifier assignment for participants 



<transaction identifier of participant> = (<transaction identifier of the conference> + 
<offset of participant>) modulo 7 



If 

1. the active full-duplex speech session exists and the SC UE does not have a subscription as described in 
subclause 7.2.2 for the active full-duplex speech session; and 

2. the SC UE has a subscription as described in subclause 7.2.2 for the additional transferred session; 

then the SC UE shall associate the participants extracted in subclause 9.1 A with transaction identifiers calculated as in 
the table 9.2.1A-2 and with TI flag of the additional transferred session. The offsets 0, 1, 2, 3, 4 are assigned to the 
participants in their order in the list of the extracted participants. 

9.2.1 B SC UE procedures for PS to CS access transfer with MSC server 
assisted mid-call feature for speech and video session 

When PS to CS access transfer occurs, with a speech and video session and another speech session using PS media in 
the SC UE, the SC UE applies the MSC Server assisted mid-call feature according to the procedures described in 
subclause 9.2. lA with the following additions: 

if the SC UE supports SCUDIF feature, and the speech and video session is active and speech session is inactive 
the SC UE shall transfer the active speech and video session as specified in subclause 9.2.1, and indicate the 
support of SCUDIF in the CC SETUP message as specified in 3GPP TS 24.008 [8], with multimedia bearer 
capability preferred for the current active session; and 

- if the SC UE supports SCUDIF feature, and the speech and video session is inactive and speech session is active, 
the SC UE shall transfer the speech session as specified in subclause 9.2.1, and indicate the support of SCUDIF 
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in the CC SETUP message as specified in 3GPP TS 24.008 [8], with speech bearer capability preferred for the 

current active session. 

NOTE: After successful transfer of the speech and video session and another speech session from PS to CS, the 

UE can switch between the two sessions by holding/releasing the active session and resuming the inactive 
session as specified in 3GPP TS 24.008 [8], with the addition that the UE can initiate the in-call 
modification or Redial procedures as specified in 3GPP TS 24.008 [8] to change the shared CS bearer of 
the two sessions from speech to multimedia, or vice versa. 

9.2.2 SC UE procedures for CS to PS access transfer 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CS call setup procedure is complete, e.g. a CC CONNECT message has been sent or 
received as described in 3GPP TS 24.008 [8] or a call for which the SIP 2xx response for the initial SIP INVITE request 
to establish this session has been sent or received. 

If not already registered in the IM CN subsystem, the SC UE shall follow the procedures specified in subclause 6.2 to 
perform registration over the Target Access Leg before performing CS to PS access transfer. 

If SC using ICS is enabled then if the original sessions are established using ICS capabilities as defined in 
3GPP TS 24.292 [4], then for each session to be transferred and starting with the active session, the SC UE shall send a 
SIP INVITE request to the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. The SC 
UE shall populate the SIP INVITE request as specified for PS-PS access transfer with full media transfer in 
subclause 10.2.1. 

If the original sessions are not established using ICS capabihties and the SC UE does not support the MSC Server 
assisted mid-call feature as described in subclause 9.2.3, subject to the SC_non_transferrable_media node value in the 
Communication Continuity MO (see subclause 5.27 in 3GPP TS 24.216 [5]) the SC UE shall: 

a) if more than one full-duplex speech session exists, first initiate the release of all the ongoing sessions that are 
currently not active with the UE procedures specified in 3GPP TS 24.083 [43] and then the SC UE shall transfer 
the remaining ongoing active full-duplex speech session. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send a SIP INVITE request to the SCC AS 
in accordance with the UE procedures specified in 3GPP TS 24.229 [2] . The SC UE shall populate the SIP INVITE 
request as follows: 

1) the Request-URI set to the static STI; and 

2) include in the Contact header field a pubUc GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2], if a 
GRUU was received at registration. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the CS domain. 

When the SC UE receives a CS call release message, e.g. CC DISCONNECT message as specified in 

3GPP TS 24.008 [8], from the network, the SC UE shall comply with network initiated call release procedures to 

release the CS bearer. 

9.2.3 SC UE procedures for CS to PS access transfer with MSC server 
assisted mid-call feature 

When the SC UE supports the MSC Server assisted mid-call feature, the SC UE shall populate the SIP INVITE request 
for transferring the session not using ICS capabilities as follows in addition to the procedures described in 
subclause 9.2.2: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

2. the Accept header field containing the MIME type as specified in annex D.1.3; and 

3. include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C. 
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NOTE 1 : If the original sessions are not established using ICS capabilities as defined in 3GPP TS 24.292 [4] and 
the sec AS and the SC UE support the MSC Server assisted mid-call featiu'e, up to one active and up to 
one inactive full-duplex speech session can be transferred. 

Upon receiving a SIP REFER request within the SIP session established by the SIP INVITE request for transferring the 
session not using ICS capabilities: 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Target-Dialog URI header field in the URI of the Refer-To header field; 

4. where the g.3gpp. mid-call media feature tag as specified in annex C was included in the Contact header field of 
the SIP 2xx response to the SIP INVITE request; and 

5 . containing a MIME body of MIME type specified in the annex D. 1 .3 ; 

and if the SC UE supports the MSC Server assisted mid-call feature, then the SC UE shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for an additional inactive session in accordance with the procedures specified in 
3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request as follows: 

A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field: 

a. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 

registration; and 

b. the g.3gpp.mid-call media feature tag as described in annex C; and 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" hne whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 

d. media directionality as in the "body" URI header field in the URI in the Refer-To header field of the 
received SIP REFER request. 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" Une whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 

port with nonzero value. 

Upon receiving a SIP 2xx response for the SIP INVITE request, then the SC UE shall proceed as specified in 
subclause 7.2.2. 

9.3 sec AS 

9.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionahty 
relating to access transfer: 
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SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field and not containing Inter UE Transfer SCC AS URI in the Request- 
URI. In the procedures below, such requests are known as "SIP INVITE requests due to STI". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI. In the procedures 
below, such requests are known as "SIP INVITE requests due to static STI". 

- SIP INVITE requests routed to the SCC AS containing either a static STN, a STN-SR or an IMRN (as 
described in 3GPP TS 24.292 [4]) in the Request-URI. In the procedures below, such requests are known as 
"SIP INVITE requests due to static STN". 

NOTE 1 : The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

NOTE 2: SIP INVITE requests routed to the SCC AS containing the additional transferred session SCC AS URI in 
the Request-URI which are used in the PS-CS access transfer with the MSC server assisted mid-call 
feature are handled by the PS -PS access transfer procedure as described in subclause 10.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

9.3.2 SCC AS procedures for PS to CS access transfer 

This subclause does not apply to reception of a SIP INVITE request due to STI with CS media and other kind of media 
or without CS media. 

When the SCC AS receives a SIP INVITE request due to STI with CS media only on the Target Access Leg, the SCC 
AS shall follow the procedures specified in subclause 10.3.2 with the following exceptions: 

- As the SIP INVITE request includes an active speech media component using CS bearer, then the SCC AS shall 
follow the procedures for SCC AS for service control over Gm in 3GPP TS 24.292 [4] to send the PSI DN to the 
SC UE and wait for the SC UE to set up CS bearer before sending SIP re-INVITE to the remote end. 

- The SCC AS shall correlate the STI with the allocated PSI DN in order to identify the remote leg to be updated. 

When the SCC AS receives SIP INVITE request due to static STN, the SCC AS shall associate the SIP INVITE request 
with an ongoing dialog supporting a session based on information associated with the received IMRN (as described in 
3GPP TS 24.292 [4]) or based on information from the SIP History-Info header field or P-Asserted-Identity header field 
or Contact header field, and send a SIP re-INVITE request towards the remote UE using the existing established dialog. 
By an ongoing dialog supporting a session, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE 
request has been sent or received. Multiple dialogs supporting a session associated with the same SC UE may have been 
anchored when the SCC AS receives a SIP INVITE request due to static STN. This can occur in the event that the UE 
does not succeed in releasing all dialogs supporting a session with inactive audio media or if the UE applies the MSC 
Server assisted mid-call feature. The identification of the associated dialog is subject to the following conditions: 

1 . if only one dialog supporting a session with active audio media exists for the user identified in the P-Asserted- 
Identity header field and a SIP 2xx response has been sent, then continue the session transfer with the dialog 
supporting a session with active audio media; 

2. if no dialogs supporting a session with active audio media exist for the user identified in the P-Asserted-ldentity 
header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid- 
call feature as specified in subclause 9.3. 2A, then send a SIP 480 (Temporarily Unavailable) response to reject 
the SIP INVITE request relating to the session transfer; 

3. if more than one dialog supporting a session with active audio media exists for the user identified in the P- 
Asserted-Identity header field for which SIP 2xx responses have been sent, then the SCC AS shall perform 
session transfer procedures for the dialog that originates from the same device that initiated the received SIP 
INVITE request due to static STN. If more than one such dialogs exists from the same device, the SCC AS shall 
proceed with the next step in this list; and 

NOTE 1: Whether the dialog originates from the same UE as the received SIP INVITE request is determined based 
on local information and information related to the correlation MSISDN or the GRUU of the originating 
user as determined via registration procedures as defined in subclause 6.3. 



ETSI 



3GPP TS 24.237 version 10.2.0 Release 10 



33 



ETSI TS 124 237 VI 0.2.0 (2011-04) 



4. if more than one dialog supporting a session exists for the user identified in the P-Asserted-Identity header field 
and exactly one dialog supporting a session with active audio media exists and a SIP 2xx response has been sent 
for that dialog, then: 

- if the sec AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, then 

the sec AS may release the dialogs supporting a session with inactive audio media and continue the session 
transfer procedures with the dialog supporting a session with active audio media; or 

- if the sec AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

5. if more than one dialog supporting a session with active audio media exist for the user identified in the P- 
Asserted-Identity header field and a SIP 2xx response has been sent for that dialog, then: 

- if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, the 
SCC AS may release all dialogs supporting a session with audio media of the user identified in the P- 
Asserted-Identity header field for which a SIP 2xx response has been sent except the one with the active 
audio media that was most recently made active and continue the session transfer procedures; or 

- if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) set the contact header field to the contact header field provided by the served UE at the creation of the dialog 
with the remote UE; and 

3) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to static STN, 
by following the rules of 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request from the IM CN subsystem, then: 

if the source access leg contains only one audio media components the SCC AS shall initiate release of the 
source access leg by sending a SIP BYE request toward the S-CSCF for sending to the served SC UE; or 

- If the Source Access Leg contains media components other than audio media component, the SCC AS should 
send a SIP re-INVITE request to update the source access leg. 

9.3.2A SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature 

The SCC AS shall apply the MSC Server assisted mid-call feature if: 

1. the Contact header field of the SIP INVITE request due to static STN includes the g.3gpp.mid-call media feature 
tag as specified in annex C; 

2. one of the following is true: 

A. at least one dialog supporting a session with active audio media exists for the user identified in the P- 
Asserted-Identity header field and the Contact header field provided by the SC UE at the establishment of the 
dialog supporting a session with active audio media which has been most recently made active includes the 
g.3gpp.mid-call media feature tag as described in annex C; or 

B. no dialog supporting a session with active audio media exists for the user identified in the P-Asserted-Identity 
header field, one or more dialogs supporting a session with inactive audio media exists for the user and the 
Contact header field provided by the SC UE at the establishment of the dialog supporting a session with 
inactive audio media which became inactive most recently includes the g.3gpp.mid-call media feature tag as 
described in annex C; 

3. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 
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4. the sec AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, and before determining that the SCC AS is not able to identify one dialog for session transfer, the SCC 
AS may: 

1. if more than one dialog supporting a session exists for the user identified in the P-Asserted-Identity header field, 
and exactly one dialog supporting a session with active audio media exists, and a SIP 2xx response has been sent 
for that dialog and there is at least one remaining dialog supporting a session with inactive audio media, release 
all dialogs supporting a session with inactive audio media except the one with the audio media which became 
inactive most recently and continue the session transfer procedures with the dialog supporting a session with 
active audio media; 

2. if more than one dialog supporting a session with active audio media exists for the user identified in the P- 
Asserted-Identity header field and a SIP 2xx response has been sent for these dialogs, release all dialogs 
supporting a session with audio media except two with the audio media which became active most recently and 
continue the session transfer procedures with the dialog supporting a session with the audio media which became 
active most recently; and 

3. if no dialog supporting a session with active audio media exists for the user identified in the P-Asserted-Identity 
header field, one or more dialogs supporting a session with inactive audio media exists for the user and a SIP 2xx 
response has been sent for these dialogs then the SCC AS may release all dialogs supporting a session with audio 
media except the one with the audio media which became inactive most recently and continue the session 
transfer procedures with the dialog supporting a session with inactive audio media. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the g.3gpp.mid-call media feature tag as described in annex C in the Contact 
header field of the SIP 2xx response to the SIP INVITE request due to static STN. 

When the SCC AS applies the MSC Server assisted mid-call feature and a dialog supporting a session with inactive 

audio media was associated with the SIP INVITE request due to static STN, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall set the directionality of the audio media in the SDP offer as used in the session with 
remote UE. 

If: 

- the SCC AS applies the MSC Server assisted mid-call feature; 

- the session associated with the SIP INVITE request due to static STN is related to a subscription as described in 
subclause 7.3.3; and 

- a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE 
within the related subscription; 

then the SCC AS shall send a SIP INFO request towards the MSC Server as specified in 3GPP TS 24.229 [2] and 
IETF RFC 6086 [54] in the dialog created by the SIP INVITE request due to static STN. The SCC AS shall populate the 
SIP INFO request as follows: 

1 . include the Info-Package header field as specified in IETF RFC 6086 [54] with g.3gpp. mid-call package name; 
and 

2. include application/vnd.3gpp.mid-call-Hxml XML body contaning the participants extracted as specified in the 
subclause 9.1 A of the subscription related to the session associated with the SIP INVITE request due to static 
STN as described in subclause 7.3.3. 

If the SCC AS appUes the MSC Server assisted mid-call feature, two SIP dialogs supporting a session with an audio 
media exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for those 
dialogs then the SCC AS shall send a SIP REFER request towards the MSC Server in accordance with the procedures 
specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP 
INVITE request due to static STN. The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 
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3. the Refer-To header field containing the information related to the additional transferred session, i.e. session 
with an audio media other than the session associated with the SIP INVITE request due to static STN, i.e. set to 
the additional transferred session SCC AS URI and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the SC UE; 

B. the Require URI header field populated with the option tag value "tdialog"; 

C. the To URI header field populated as specified in IETF RFC 3261 [19], containing the P-Asserted-Identity 
provided by the remote UE during the session establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user identity 
of the SC UE provided during the session establishment; 

E. the Content-Type header field with "application/sdp"; and 

F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 

session with the remote UE and: 

a. if directionality used by SC UE is "sendrecv" or "sendonly", with the "sendonly" directionaUty; and 

b. if directionality used by SC UE is "recvonly" or "inactive", with the "inactive" directionality. 

4. the Content-Type header field with the value set to MIME type as specified in the annex D. 1 .3 ; and 

5 . a XML body compliant to the XML schema specified in the annex D. 1 .2. If 

A. the session associated with the SIP INVITE request due to static STN is not related to any subscription as 
described in subclause 7.3.3; 

B. the additional transferred session is related to a subscription as described in subclause 7.3.3; and 

C. a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE 
within the related subscription; 

then SCC AS shall populate the XML body with the participants extracted as specified in the subclause 9.1 A of 
the subscription related to the additional transferred session as specified in subclause 7.3.3. 



9.3.3 SCC AS procedures for CS to PS access transfer 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg offering PS media only, the 
SCC AS shall follow the procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to static STI, the SCC AS shall associate the SIP INVITE 
request with an ongoing dialog supporting a session. By an ongoing dialog supporting a session, it is meant a dialog for 
which a SIP 2xx response to the initial SIP INVITE request has been sent or received. Multiple dialogs supporting a 
session associated with the same SC UE may have been anchored when the SCC AS receives a SIP INVITE request due 
to static STI. This can occur in the event that the UE does not succeed in releasing all dialogs supporting a session with 
inactive audio media or if the UE supports the MSC Server assisted mid-call feature, in which case the identification of 
the associated dialog is subject to the following conditions: 

1. if only one dialog supporting a session with active audio media exists for the user identified in the P-Asserted- 
Identity header field and a 2xx response has been sent, then continue the session transfer procedures; 

2. if no dialogs supporting a session with active audio media exist for the user identified in the P-Asserted-Identity 
header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid- 
call feature as specified in subclause 9.3.4, then send a SIP 480 (Temporarily Unavailable) response to reject the 
SIP INVITE request relating to the session transfer; 

3. if more than one dialog supporting a session exists for the user identified in the P-Asserted-Identity header field 
and exactly one dialog supporting a session with active audio media and a SIP 2xx response has been sent for 
that dialog, then: 
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A. if the remaining dialogs support a session with inactive audio media and the SCC AS does not apply the 
MSC Server assisted mid-call feature as specified in subclause 9.3.4, then the SCC AS may release the 
dialogs supporting a session with inactive audio media and continue the session transfer procedures with the 
dialog supporting a session with active audio media; and 

4. if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS sends a SIP re-INVITE request towards the remote UE using 
the existing established dialog. The SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to the static STI, 
by following the rules of 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request originated from the UE, the SCC AS shall initiate release of the source access leg 
by sending a SIP BYE request over the source access leg. 

If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request originated 
from the UE being received from the IM CN subsystem for the source access leg, the SCC AS decides (for any reason) 
to reject the session transfer request back to the UE (e.g. by sending a SIP 4xx response), the SCC AS shall release the 
target access leg and maintain the source access leg. 

9.3.4 SCC AS procedures for CS to PS access transfer with MSC server 
assisted mid-call feature 

The SCC AS shall apply the MSC Server assisted mid-call feature if: 

1. the Contact header field of the SIP INVITE request due to static STI includes the g.3gpp.mid-call media feature 
tag as specified in annex C; 

2. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.3, and before determining that the SCC AS is not able to identify one dialog for session transfer, SCC AS 

may: 

1. if more than one dialog exists for the user identified in the P-Asserted-Identity header field, and exactly one 
dialog supporting a session with active audio media exists, and a SIP 2xx response has been sent for that dialog 
and there is at least one remaining dialog supporting a session with inactive audio media, release all dialogs 
supporting a session with inactive audio media except the one with the audio media which became inactive most 
recently and continue the session transfer procedures with the dialog supporting a session with active audio 
media ; and 

2. if no dialog supporting a session with active audio media exists for the user identified in the P-Asserted-Identity 
header field, one or more dialogs supporting a session with inactive audio media exists for the user and a SIP 2xx 
response has been sent for these dialogs then the SCC AS may release all dialogs supporting a session with audio 
media except the one with the audio media which became inactive most recently and continue the session 
transfer procedures with the dialog supporting a session with inactive audio media. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the g.3gpp.mid-call media feature tag as described in annex C in the Contact 
header field of the SIP 2xx response to the SIP INVITE request due to static STI. 

When the SCC AS applies the MSC Server assisted mid-call feature and a dialog supporting a session with inactive 

audio media was associated with the SIP INVITE request due to static STI, in addition to the procedures described in 
subclause 9.3.3, the SCC AS shall set the directionality of the audio media in the SDP offer as used in the session with 
remote UE. 
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If the sec AS applies the MSC Server assisted mid-call feature, two SIP dialogs supporting a session with an audio 
media exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for those 
dialogs then the SCC AS shall send a SIP REFER request towards the SC UE in accordance with the procedures 
specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP 
INVITE request due to static STL The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the information related to the session with an audio media other than the 
session associated with the SIP INVITE request due to static STI, i.e. set to the additional transferred session 
SCC AS URI and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the MSC Server; 

B. the Require URI header field populated with the option tag value "tdialog"; 

C. if the remote UE did not request privacy then the To URI header field populated as specified in 

IETF RFC 3261 [19], containing the P-Asserted-Identity provided by the remote UE during the session 
establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the pubUc user identity 
of the SC UE provided during the session establishment; 

E. the Content-Type URI header field with "application/sdp"; and 

F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 
session with the remote UE and with directionality as used by the MSC Server; 

4. the Content-Type header field with the value set to MIME type specified in the annex D.1.3; and 

5. a XML body compliant to the XML schema specified in the annex D. 1.2. 

9.4 MSC server enhanced for ICS 

If the MSC server enhanced for ICS has registered for the user, it shall apply the procedures as specified in 
3GPPTS 29.292 [18]. 

If the MSC server enhanced for ICS supports the MSC server assisted mid-call feature, it shall apply the procedures 
specified in subclause 9.5 and subclause 9.6. 

9.4.1 Void 
9.4.1A Void 

9.5 PS to CS session continuity with IVISC server assisted mid- 
call feature 

This subclause describes the procedures required by an MSC server in order to support the MSC server assisted mid call 
feature. 

The MSC server shall populate the SIP INVITE request as follows: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

2. the Accept header field containing the MIME type as specified in annex D.1.3; 

3. include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C; and 
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4. the Recv-Info header field containing the g.Bgpp.mid-call package name. 

NOTE 1 : Since the MSG server is not able to distinguish the dual radio access transfer fi-om the regular session set 
up, the information elements above are added to every SIP INVITE request sent by the MSG server. 

Upon receiving a SIP INFO request with the Info-Package header field containing the g.3gpp.niid-call package name, if 
the SIP INVITE request established a session with conference focus, then the MSG server shall associate the 
participants extracted from the application/vnd.3gpp.mid-call+xml MIME body with transaction identifiers calculated 
as in the table 9.2.1A-2 and with TI flag of the session. The offsets 0, 2, 3, 4, 5 are assigned to the participants in their 
order in the Ust of the extracted participants. 

Upon receiving a SIP REFER request 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field; 

4. sent inside an existing SIP dialog: 

A. which was originated by the MSG server; and 

B. where the g.3gpp.rmd-call media feature tag as specified in annex G was included in the Gontact header field 
of the SIP 2xx response to the SIP INVITE request; and 

5 . containing a MIME body of MIME type specified in the annex D. 1 .3 ; 
the MSG server shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 L2J, IETF REG 3515 [13] and 
IETF REG 4488 [20]; and 

2. send a SIP INVITE request for transfer of an additional inactive session not using IGS capabilities in accordance 
with the procedures specified in 3GPP TS 24.229 [2] and IETF REG 3515 [13]. Additionally, the MSG server 
shall populate the SIP INVITE request as follows: 

A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF REG 3261 [19] except the "body" URI header field; 

B. include in the Gontact header field the g.3gpp.mid-caU media feature tag as described in annex G; and 
G. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" Une whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 

d. media directionality as in the "body" URI header field in the URI in the Refer-To header field of the 

received SIP REFER request 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" Une whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 

If two sessions are transferred, the MSG server shall: 

1 . associate the SIP INVITE request for an additional inactive session with GS call with transaction identifier 
calculated as in the table 9.2.1A-1 and TI flag value as in mobile originated call; and; 

2. if the SIP INVITE request for an additional inactive session established a session with conference focus then 
associate the participants extracted from the apphcation/vnd.3gpp.mid-call+xml MIME body included in the SIP 
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REFER request with transaction identifiers calculated as in the table 9.2.1A-2 and with TI flag of the session. 
The offsets 0, 1, 2, 3, 4 are assigned to the participants in their order in the list of the extracted participants. 

9.6 PS to CS session continuity with IVISC server assisted mid- 
call feature for speech and video session 

This subclause describes the procedures required by an MSC server in order to support the MSG server assisted mid call 
feature for speech and video session. 

The MSC server , upon receiving the session state information which indicates an inactive speech and video session, 
shall send a SIP INVITE request for the additional inactive speech and video session as described in subclause 9.5. 

NOTE 1: If due to some reason (i.e. the current RAN type not supporting video, lack of resource, etc.) the video 

media can not be supported in CS network for the speech and video session, then the MSC server can set 
the port to zero in the "m=" line for the video media in the SDP offer of the SIP INVITE request for the 
additional inactive session, so as to inform the SCC AS that the video media is deleted and only the audio 
media of the speech and video session is transferred to CS. 

NOTE 2: After successful transfer of a speech and video session and a speech session from PS to CS, if messages 
are received from the UE to switch between the two sessions (i.e. HOLD/Release message to hold/release 
the active session and Retrieve message to retrieve the inactive session), the MSC server can perform the 
procedures as specified in 3GPP TS 29.292 [18], with the addition that the MSC server can complete the 
in-call modification or Redial procedures as specified in 3GPP TS 24.008 [8] to change the shared CS 
bearer of the two sessions from speech to multimedia, or vice versa, before sending a SIP UPDATE or 
SIP re-INVITE message to the SCC AS to resume the inactive session. 



1 Roles for PS-PS access transfer 
10.1 Introduction 

This clause specifies the procedures for PS-PS access transfer for both full media transfer case and partial media 
transfer case. Procedures are specified for the SC UE and the SCC AS. 



10.2 SCUE 
10.2.0 General 

The SC UE may be engaged in one or more ongoing sessions or in one or more SIP dialogs in early state before 
performing access transfer. By an ongoing session, it is meant a session for which the SIP 2xx response for the initial 
SIP INVITE request to establish this session has been sent or received. By a SIP dialog in early state, it is meant an 
early SIP dialog which has been created by a provisional response to the initial SIP INVITE request, but for which the 
SIP 2xx response has not yet been sent or received. 

The SC UE shall follow the procedures specified in subclause 6.1 to perform registration in the IM CN subsystem on 
the newly selected access network before performing PS-PS access transfer. When registering a new contact address, 
the SC UE may either: 

a) not employ the multiple registration mechanism. In this case, upon the registration of the new contact address, all 
dialogs associated with the old contact address are terminated by the S-CSCF. The terminated dialogs include the 
dialog over the Source Access Leg and the SC UE's subscription dialog to its reg-event; or 

NOTE 1 : Since the SCC AS retains the information pertaining to the dialog on the Source Access Leg, as specified 
in subclause 10.3.4, upon receiving an initial INVITE request (i.e. on the Targer Access Leg) containing 
the Replaces header field, the SCC AS will be able to identify the dialog toward the the remote UE 
associated with the dialog on the Source Access Leg being replaced. 

b) employ the multiple registration mechanism. In this case, the SC UE may either: 
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- add new flow that terminates at the new contact address, and leave all dialogs associated with the old flow 

and old contact address intact; or 

- replace the old flow that terminates at the old address with a new flow that terminates at the new contact 
address, resulting in all dialogs associated with the old flow and old contact address being terminated 
(include the dialog over the Source Access Leg and the SC UE's subscription dialog to its reg-event). 

NOTE 2: Since the SCC AS retains the information pertaining to the dialog on the Source Access Leg, as specified 
in subclause 10.3.4, upon receiving an initial INVITE request (i.e. on the Targer Access Leg) containing 
the Replaces header field, the SCC AS will be able to identify the dialog toward the the remote UE 
associated with the dialog on the Source Access Leg being replaced. 

NOTE 3: When transferring all media from the Source Access Leg to the Target Access Leg, the SC UE may 
replace the old flow with a new flow, and let the network terminate all dialogs and the registration 
associated with the old flow, rather then the SC UE performing these actions itself. 



10.2.1 Full session transfer 

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request over the Target Access Leg 
in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request 

as follows: 



1. the Request- URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

2. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B. the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3. select one of the following options: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the session to be transferred; and 

b. the Require header field populated with the option tag value "replaces"; 

B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 

identifier of the session to be transferred; and 

b. the Require header field populated with the option tag value "tdialog"; 

4. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same 
number of media lines in the same order, where each media line corresponds to one of the media components in 
the original session, unless media components need to be added, and such that each media line indicates the 
same media type as its corresponding media component in the original session and contains at least one codec 
that was negotiated during the original session. 

A. If the SC UE determines to remove a media component during the transfer, then the SC UE shall set the 
media line for this media component to a port number with value zero; and 

B. If the SC UE determines to add new media component(s) during the transfer, then the SC UE shall include 
one additional media line with the desired media type and codecs for each new media component at the end 
of the SDP; and 

5. if the Source Access Leg is an early dialog and the session was created by a received SIP INVITE request, 
indicate support of the info package mechanism as specified in IETF RFC 6086 [54]. 
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NOTE 1: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 
control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabilities (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request: 

if the dialog over the Source Access Leg was a confirmed dialog and if it is still active, the SC UE shall send a 
SIP BYE request to the SCC AS over the Source Access Leg to terminate the original session. 

- If the dialog over the Source Access Leg was an early dialog and if it is stiU active, the SC UE shall send a SIP 
CANCEL if the transferred session was originated by the UE over the source access, or a SIP 410 (Gone) response if 
the transferred session was terminated by the UE over the source access. 

NOTE 2: If the contact address used by the dialog over the Source Access Leg was registered using multiple 

registration procedure, and the flow over the Target Access Leg did not replace the flow over the Source 
Access Leg, then upon transferring the dialog to the Target Access Leg, the SC UE is still registered on 
the Source Access Leg and its subscription dialog to its reg-event the Source Access Leg is intact. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS access transfer has not completed successfully and the call will continue in the Source Access Leg. 

When the session: 

- was created by a received SIP INVITE request; and 

- was transferred using PS-PS access transfer procedures when the session was an early dialog; 

then when the session is accepted the SC UE shall send the SIP INFO request inside the Target Access Leg containing: 

1. an Info-Package header field as specified in IETF RFC 6086 [54] with g.3gpp.state-and-event info package 
name; and 

2. application/vnd.3gpp.state-and-event-info+xml XML body with the event XML element containing "call- 
accepted" to indicate that the called party has answered the call. 

1 0.2. 1 A Additional procedures for full session transfer when MSG server 
assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.1, if the SC UE supports the MSC Server assisted mid-call 
feature, the SC UE shall include in the Contact header field of the SIP INVITE request the g.3gpp.mid-call media 
feature tag as described in annex C. 

10.2.2 Partial session transfer 

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request over the Target Access Leg 
in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request 
as follows: 

1 . the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

2. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B. the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3. the Require header field with the option tag 'tdialog' included; 
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4. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 

the session to be transferred; and 

5. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same 
number of media lines in the same order, where each media line corresponds to one of the media components in 
the original session, unless media components need to be added during the session transfer, and such that each 
media line indicates the same media type as its corresponding media component in the original session and 
contains at least one codec that was negotiated during the original session. 

A. If the SC UE determines to keep the media component on the Source Access Leg, then the SCUE shall set 
the media line for this media component to a port number with value zero; and 

B. If the SC UE determines to add new media component(s) during the transfer, then the SC UE shall include 
one additional media line with the desired media type and codecs for each new media component at the end 
of the SDP. 

NOTE: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 
control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabilities (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, the SC UE shall send a SIP re-INVITE request to the SCC AS over the Source Access Leg to update the 
original session. The SC UE shall populate the SIP re-INVITE request as follows: 

1 . the SDP payload set for all the media component(s) within the original session, in accordance with the UE SDP 
origination procedures specified in 3GPP TS 24.229 [2]. The SC UE shall set the port number for a media 
component to zero if that media component has been transferred to the Target Access Leg or has to be removed. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS access transfer has not completed successfully and the call will continue in the Source Access Leg. 

1 0.2.3 Additional procedures for partial session transfer when MSG server 
assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.2, if the SC UE supports the MSC Server assisted mid-call 
feature, the SC UE shall include in the Contact header field of the SIP INVITE request the g.3gpp.mid-call media 
feature tag as described in annex C. 

10.3 SCC AS 

1 0.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific fimctionaUty 
relating to access transfer: 

- SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field and not containing Inter UE Transfer SCC AS URI in the Request- 
URI. In the procedures below such requests are known as "SIP INVITE requests due to STI". 

NOTE 1: If the Request-URI contains the additional transferred session SCC AS URI, the PS-PS access transfer 

procedure is used to transfer the additional transferred session during PS-CS access transfer with the MSC 
server assisted mid-call feature. 

NOTE 2: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 
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Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 0.3.2 PS to PS access transfer procedures at the SCC AS 

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only. 

When the SCC AS receives a SIP INVITE request on the Target Access Leg due to STI, the SCC AS shall: 

associate the SIP INVITE received on the Target Access Leg with a previously established SIP dialog or a SIP 
dialog in early state i.e. identify the Source Access Leg. The SIP dialog on the Source Access Leg is identified 
by matching the dialog ID present in the Replaces (see IETF RFC 3891 [10]) or Target Dialog header field (see 
IETF RFC 4538 [11]) of the SIP INVITE with the previously estabhshed SIP dialog or with a dialog in early 
state. By a previously established SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP 
INVITE request has been sent or received. By a SIP dialog in early state, it is meant an early SIP dialog which 
has been created by a provisional response to the initial SIP INVITE request, but for which the SIP 2xx 
response has not yet been sent or received; 

if the SCC AS is unable to associate the SIP INVITE with a unique previously estabhshed SIP dialog or dialog 
in early state, send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to 
the access transfer and not processes the remaining steps; 

if the SIP INVITE request contains a Replaces header field: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [8] in case the Source Access Leg was an 
ongoing dialog, or by sending a SIP CANCEL request towards the SC UE in case the Source Access Leg was 
a dialog in early state and it was terminating for the SC UE, or by sending a SIP 410 (Gone) response 
towards the SC UE in case the Source Access Leg was a dialog in early state and it was originating for the 
SC UE; and 

b) either send a SIP re-INVITE request towards the remote UE using the existing established dialog or send SIP 
UPDATE request(s) towards the remote UE(s) using the existing early dialog(s) which were created by the 
same INVITE request as the Source Access Leg. The SCC AS shall populate the SIP re-INVITE request or 
the SIP UPDATE request (s) as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 

with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to STI 
received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. 

- otherwise, if the SIP INVITE request contains a Target Dialog header field: 

a) if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media hnes is not the same as in the original session, 
send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the 

remaining steps; 

b) otherwise, either send a SIP re-INVITE request towards the remote UE using the existing estabhshed dialog 
or send a SIP UPDATE request(s) towards the remote UE(s) using the existing early dialog(s) which were 
created by the same INVITE request as the Source Access Leg. The SCC AS shall populate the SIP re- 
INVITE or the SIP UPDATE request(s) as follows: 



1) 



void; and 



2) 



include a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following 
media information: 



- the media characteristics as received in the SIP INVITE request due to STI received on the Target 
Access Leg for media streams whose port is not set to zero; and 
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for the media streams in the SIP INVITE request due to STI whose port is set to zero, include the 
corresponding media characteristics of those streams from the Source Access Leg, 

c) for a full media transfer, send a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [2] in case 
the Source Access Leg was an ongoing dialog, or send a SIP CANCEL request towards the SC UE in case 
the Source Access Leg was a dialog in early state and it was terminating for SC UE, or send a SIP 410 
(Gone) response towards the SC UE when the Source Access Leg was a dialog in early state and it was 
originating for SC UE; otherwise, for a partial media transfer, after receiving the SIP ACK request from the 
SC UE on the Target Access Leg, upon receiving an update (e.g. SIP re-INVITE) from the SC UE on the 
Source Access Leg, process the update request in accordance with 3GPP TS 24.229 [2]. 

If the Remote Leg is an early dialog then when receiving SIP 2xx response to the SIP UPDATE request, the SCC AS 
shall send SIP 183 (Session Progress) response to the SIP INVITE request due to STI. The SCC AS shall populate the 
SIP response as follows: 

1 . if the Remote Leg is an early dialog originated by the remote UE: 

1 . the Recv-Info header field containing the g.3gpp.state-and-event package name; and 

2. the Accept header field containing the application/vnd.3gpp.state-and-event-info+xml MIME type. 

If, subsequent to initiating the SIP re-lNVITE request or the SIP UPDATE request to the remote UE, and prior to the 
SIP ACK request being received on the Target Access Leg, the SCC AS decides (for any reason) to reject the access 
transfer request (e.g. by sending a 4xx response), the SCC AS shall release the Target Access Leg, retain the Source 
Access Leg, and update the remote leg to match the Source Access Leg. 

If the Remote Leg is an early dialog originated by the remote UE then when receiving the SIP INFO request inside the 
Target Access Leg containing: 

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; 
and 

2. application/vnd.3gpp.state-and-event-info+xml XML body with the event XML element containing "call- 
accepted" to indicate that the called party has answered the call; 

then the SCC AS shall: 

1 . send SIP 200 (OK) response to the SIP INVITE request to the remote UE; and 

2. send SIP 200 (OK) response to the SIP INVITE request over the Target Access Leg. 

1 0.3.3 Additional SCC AS procedures for PS to PS access transfer wlien 
MSG server assisted mid-call feature is supported 

If: 

1. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; 

2. the g.3gpp.mid-call media feature tag as described in annex C is included in the Contact header field of the SIP 
INVITE request due to STI; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

then the SCC AS shall include the g.3gpp.mid-caU media feature tag as described in annex C in the Contact header field 
of the SIP 2xx response to the SIP INVITE request due to STI in addition to the procedures described in 
subclause 10.3.2. 

1 0.3.4 S-CSCF releasing the source access leg during PS to PS access 
transfer 

When SCC AS receives a SIP BYE request on an existing dialog on the Source Access Leg with the status code 480 
(Temporarily Unavailable) in a Reason header field indicating that this dialog was released by the S-CSCF, the SCC AS 
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shall delay the release of the dialog toward the the remote UE and retaining the information pertaining to the dialog on 
the Source Access Leg for a specific time interval. If the SCC AS: 

a) receives within this time interval an initial INVITE request (i.e. on the Targer Access Leg) indicating that this 
dialog is replacing the dialog on the Source Access Leg, then the SCC AS shall not initiate the release of the 
dialog toward the the remote UE; or 

NOTE 1: By retaining the information pertaining to the dialog on the Source Access Leg, and upon receiving an 
initial INVITE request (i.e. on the Targer Access Leg), the SCC AS wiU be able to identify the dialog on 
the Source Access Leg and the associated dialog toward the the remote UE. 

b) does not receive within this time interval an initial INVITE request (i.e. on the Targer Access Leg) indicating 
that this dialog is replacing the dialog on the Source Access Leg, then the SCC AS shall initiate the release of the 
dialog toward the the remote UE and delete the information pertaining to the dialog on the Source Access Leg. 

NOTE 2: The time interval is defined by the operator poUcy. The value of 8 seconds is an appropriate value for the 
time interval. 

NOTE 3: When the UE, prior to sending the initial INVITE request on the Target Access Leg, registers new contact 
address and either uses the multiple registrations where new flow on the Target Access Leg replaces an 
old flow on the Source Access Leg or does not uses the multiple registrations, the S-CSCF will terminate 
all dialogs associated with the old constant address or old flow, as specified in 24.229. By retaining the 
information pertaining to the dialog on the Source Access Leg, the SCC AS knows which dialog is being 
replaced. 



1 1 Roles for PS-PS access transfer in conjunction witli 
PS-CS access transfer 

11.1 Introduction 

This clause specifies the procedures for PS-PS access transfer in conjunction with PS-CS access transfer. Procedures are 
specified for the SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-PS access transfer 
with a remote end in conjunction with PS-CS access transfer with the same remote end is only possible when the UE is 
active in a single CS session with full-duplex speech with the remote end i.e. support of session transfer with more than 
one session containing full-duplex speech component is not provided. 

11.2 SCUE 

1 1 .2.1 SC UE procedures for PS to PS+CS access transfer 

11.2.1.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been 
sent or received. 

1 1 .2.1 .2 SC UE procedures for PS to PS+CS access transfer using ICS 

This subclause applies for IMS sessions containing not only speech media component, otherwise subclause 9.2.1 
applies. 

If SC using ICS is enabled then if the SC UE is using Gm, then for each session to be transferred and starting with the 
session with active full-duplex speech component, the SC UE shall send a SIP INVITE request to the SCC AS as 
specified for call origination for ICS UE using Gm in 3GPP TS 24.292 [4]. The SC UE shall populate the SIP INVITE 
request as specified for PS-PS access transfer with full media transfer in subclause 10.2.1 with the following exceptions: 
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- The SC UE shall indicate in the SIP INVITE request that the speech media is using CS bearer with its 

corresponding media description. 

- When sending the SIP INVITE request for the sessions with inactive full-duplex speech component and if 
precondition is used, the SC UE shall indicate that the related local preconditions for the speech component are 
met. 

For the session with active full-duplex speech component, upon receiving the PSl DN from the SCC AS, the SC 
UE shaU follow the procedures for caU origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up the CS 
bearer. 

If service control over Gm for the CS bearer is retained on the source access leg, the SC UE shall: 

- send an SIP INVITE request as specified for partial session transfer in subclause 10.2.2. indicating transfer of 
non-speech media to the target access leg; and 

- send a SIP re-INVITE request over the source access leg indicating that the speech media is to be transferred to a 
CS bearer as described in 3GPP TS 24.292 [4] subclause 8.2.2.2. If other media components are retained or 
added on the source access leg, then these are included in the SDP offer. 

For the session with active full-duplex speech component, upon receiving the SCC AS PSI DN from the SCC AS, the 
SC UE shall follow the procedures for call origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up the CS 
bearer. 

1 1 .2.1 .3 SC UE procedures for PS to PS+CS access transfer not using ICS 

If the SC UE is not using ICS capabilities and if the SC UE does not apply the MSC server assisted mid-call feature as 
specified in subclause 9.2.1 A, then access transfer is only possible when the UE is active in a single session with full- 
duplex speech media component. 

For the non-speech components to be transferred to the PS Target Access Leg, the SC UE shall send a SIP INVITE 
request to the SCC AS as specified for PS-PS access transfer with partial media transfer in subclause 10.2.1. For the 
speech component to be transferred to the CS Target Access leg, the SC UE shall send to the SCC AS a CC SETUP 
message as specified in 3GPP TS 24.008 [8]. When sending the CC SETUP message, the SC UE shall populate the CC 
SETUP message as follows: 

1) the called party BCD number information element set to the STN; 

2) Type Of Number set to "International" and Numbering Plan Indicator set to "E.164".in the Called Party BCD 
Number information element. 

Upon receiving the SIP 2xx response from the SCC AS for the PS Target Access Leg and sending SIP ACK request and 
upon receiving CS call setup confirmation message, e.g. CC CONNECT message, for the CS Target Access Leg, the 
SC UE shall send a SIP BYE request to terminate the Source Access Leg, following the procedures specified in 
3GPPTS 24.229 [2]. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access leg and receives 
CS call setup failure message for the CS Target Access Leg, then session transfer has not occurred and the call will 
continue in the original domains. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access Leg and 
receives CS call setup confirmation message for the CS Target Access Leg, then the session transfer is only successful 
for part of the media components. The SC UE shall update the Source Access leg by following the procedures specified 
for PS-PS access transfer with partial media transfer in subclause 10.2.2 to indicate that all media components other 
than the speech component are still maintained on the Source Access Leg. 

If the SC UE receives CS call setup failure message for the CS Target Access Leg but receives a SIP 2xx response for 
the PS Target Access Leg, then the session transfer is only successful for part of the media components. Upon sending 
SIP ACK request, the SC UE shall update the Source Access leg by following the procedures specified for PS-PS 
access transfer with partial media transfer in subclause 10.2.2 to indicate that the speech component is still maintained 
on the Source Access Leg. 
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1 1 .2.1 .4 SC UE procedures for PS to PS+CS access transfer not using ICS with MSG 
server assisted mid-call feature 

In addition to the procedures described in subclause 11.2.1.3 the SC UE shaU: 

- act as described in subclause 9.2. lA; and 

- if the MSG server assisted mid-caU feature is apphed, transfer the non-speech components of the additional 
transferred session to the PS Target Access Leg as specified for PS-PS access transfer with partial media transfer 
in subclause 10.2.2. 

1 1 .2.2 SC UE procedures for PS+CS to PS access transfer 

11.2.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CC CONNECT message has been sent or received or a call for which the SIP 2xx 
response for the initial SIP INVITE request to estabhsh this session has been sent or received. 

If not already registered over the PS Target Access Leg, the SC UE shall follow the procedures specified in 
subclause 6.2 to perform IM CN subsystem registration over the Target Access Leg before performing PS/CS to PS 
access transfer. 

1 1 .2.2.2 SC UE procedures for PS+CS to PS access transfer using ICS 

If SC using ICS is enabled then if the original sessions are established using ICS capabilities as defined in 
3GPP TS 24.292 [4], then for each session to be transferred and starting with the session with active full-duplex speech 
media component, the SC UE shall send a SIP INVITE request to the SCC AS in accordance with the UE procedures 
specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as specified for PS-PS access 
transfer with full media transfer in subclause 10.2.1. The SC UE shall indicate in the SIP INVITE request that the 
speech media component is using PS media. 

Upon receiving SIP BYE request for the Source Access Leg, the SC UE shall follow the ICS using Gm procedures 
specified in 3GPP TS 24.292 [4] to release the session. The SC UE also releases the associated CS bearer if no other 
sessions depend on the CS bearer. 

1 1 .2.2.3 SC UE procedures for PS+CS to PS access transfer not using ICS 

If the original sessions are not established using ICS capabilities, then access transfer is only possible when the SC UE 
has a single session with active full-duplex speech media component. The SC UE shall send a SIP INVITE request to 
the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. 

The SC UE shall populate the SIP INVITE request as follows: 

- the Request-URI set to static STI; 

the Require header field including "replaces" option tag; 

- the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier of the 
session to be transferred on the PS Source Access Leg; and 

- the SDP payload set for the media component(s) to be transferred, in accordance the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains media 
components in the following order: 

1) the same number of media lines, each corresponding to one of the media components in the session on the PS 
Source Access Leg; For each media line the SC UE shall indicate the same media type as its corresponding 
media component in the original session and indicate at least one codec that was negotiated during the 
original session. If the SC UE determines to remove a media component during the transfer, then the SC UE 
shall set the media line for this media component to include a port number with value zero; 
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2) one speech media component to be transferred, corresponding to the speech media component in the session 
on the CS Source Access Leg; and 

3) if the SC UE determines to add new media component(s) during the transfer, then one additional media line 
with the desired media type and codecs each new media component. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the original domains. 

1 1 .3 sec AS 

11 .3.1 Distinction of requests sent to tlie SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionaUty 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field and not containing Inter UE Transfer SCC AS URI in the Request- 
URI. In the procedures below, such requests are known as "SIP INVITE requests due to STI". 

SIP INVITE requests routed to the SCC AS containing either a static STN or an IMRN in the Request-URI. In 
the procedures below, such requests are known as "SIP INVITE requests due to static STN". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI and a STI in the 
Replaces or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to two STIs". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
subclauses 11.3.2 and 11.3.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 1 .3.2 SCC AS procedures for PS to PS+CS access transfer 

This subclause does not apply to recepetion of a SIP INVITE request due to STI with a CS media. 

When the SCC AS receives a SIP INVITE request due to STI with PS and CS media on the Target Access Leg, the 
SCC AS shall follow the PS-PS Access Transfer procedures specified in subclause 10.3.2. with the following 
exceptions: 

If the SIP INVITE request includes an active speech media component using CS bearer, then the SCC AS shall follow 
the procedures for SCC AS for service control over Gm in 3GPP TS 24.292 [4] to send the PSI DN to the SC UE and 
wait for the SC UE to set up CS bearer before sending re-lNVlTE to the remote UE. 

The SCC AS shall correlate the STI with the allocated PSI DN in order to identify the remote leg to be updated. 

- If service control over Gm is retained on the source access leg, and the SCC AS receives a re-INVITE request 
indicating CS bearer on an existing session, the SCC AS shall follow procedures as described in 

3GPP TS 24.292 [4] subclause 8.4.2 to send the PSI DN to the SC UE and wait for the SC UE to set up CS 

bearer before sending re-INVITE to the remote end. 

- The SCC AS shall include a new SDP offer in the re-INVITE request, following the rules specified in 
3GPP TS 24.229 [2], containing the following media information: 

- the media characteristics as received in the SIP INVITE request due to STI with PS+CS media received on 
the Target Access Leg for media streams whose port is not set to zero; and 

- the media characteristics as received in the SIP re-INVITE request for media streams whose port is not set to 
zero. 
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When the SCC AS receives a SIP INVITE request due to static STN on the Target Access Leg, the SCC AS shall 
follow the PS-CS Access Transfer procedures specified in subclause 9.3.2. However, as the Source Access Leg contains 
media components other than speech component, the SCC AS does not initiate release for Source Access Leg. 



1 1 .3.3 SCC AS procedures for PS+CS to PS access transfer 

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only. 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS access transfer procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to two STIs on the Target Access Leg, the SCC AS shall: 
associate the SIP INVITE request received on the Target Access Leg with two ongoing sessions: 

a) an ongoing SIP dialog on the PS Source Access Leg: This is done by matching the dialog ID present in the 
Replaces header field (see IETF RFC 3891 [10]) or Target-Dialog header field (see IETF RFC 4538 [11]) of 
the SIP INVITE request with an ongoing dialog. By an ongoing SIP dialog, it is meant a dialog for which a 
SIP 2xx response to the initial SIP INVITE request has been sent or received; 

b) a different ongoing SIP dialog with active full-duplex speech component: 

if the SCC AS is unable to associate the SIP INVITE request with either one of the above two dialogs, send a 
SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and 
not process the remaining steps; and 

if the session transfer is possible: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the two sessions on the Source Access 
Legs with the SIP request received on the Target Access Leg, including terminating the two Source Access 
Legs by sending a SIP BYE request on each session towards the SC UE in accordance with 

3GPPTS 24.229 [2]; and 

b) send a SIP re -INVITE request towards the remote UE using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to two 
STIs received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. 



12 Roles for PS-CS access transfer, Single Radio 
12.1 Introduction 

This clause specifies the procedures for PS-CS access transfer in Single Radio VCC. Procedures are specified for the 
SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-CS access transfer in SR-VCC is 
only possible when SC is enabled, the UE is active in a single session with full-duplex speech i.e. support of session 
transfer with more than one session containing full-duplex speech component is not provided. 

In order to fulfil the requirements for PS-CS access transfer in SR-VCC for calls in alerting state, the SC UE needs to be 
engaged in a session in early dialog state according to the following conditions before SR-VCC access transfer is 
performed: 

- a SIP 180 (Ringing) response for the initial SIP INVITE request to establish this session has been sent or 
received; and 

- a SIP final response for the initial SIP INVITE request to establish this session has not been sent or received. 
If one of the dialogs meets the above conditions then: 
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Subclauses 12.2.2, 12.2.3, 12.2. 3A and 12.2.4 shall be followed for a SC UE engaged in one or more ongoing 

sessions. 

- Subclauses 12.2. 3B and 12.2.4 shall be followed for a SC UE that is engaged in a session in early dialog state. 

12.2 SC UE procedures for PS to CS access transfer, SR-VCC 

12.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before SR-VCC access transfer is performed. By an 
ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this 
session has been sent or received. 

12.2.2 ICS-based 

If: 

- SC using ICS is enabled; 

- the Gm reference point is retained upon PS handover procedure; 

- the SC UE is using ICS capabihties as defined in 3GPP TS 24.292 [4]; and 

- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
the SC UE, in order to add Gm control for the newly established CS session, shall: 

- send a SIP re-INVITE request for each speech session to be transferred, starting with the session with active full- 
duplex speech component that was most recently made active; and 

- within the SDP offer indicate the media hne for all active and held audio streams as an audio stream over circuit 
switched bearer in accordance with 3GPP TS 24.292 [4]. If the precondition mechanism is used, the SC UE shall 
indicate the related local preconditions as met. 

NOTE: Within SR-VCC the handover is performed on PS level. Due to this, the SIP dialog established over the 
source PS access network stays the same after SR-VCC procedures, e.g. the IP address of the UE, the 
Call-ID, the P-CSCF do not change. Therefore in this case a re-INVITE needs to be sent to add ICS- 
control for the CS bearer. 

12.2.3 Not based on ICS 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8J), if the SC UE is not using ICS capabilities 
and the SC UE does not apply the MSC Server assisted mid-call feature as specified in subclause 12.2.3A, the SC UE 
shall replace the most recently active PS audio session with the newly estabhshed CS voice call. 

NOTE: In the case when ICS is not supported or used and the SC UE does not apply the MSC Server assisted 
mid-call feature, only the most recently active audio call is transferred from PS to CS audio. 

If: 

- the Gm reference point is retained upon PS handover; 

- the SC UE is not using ICS capabilities; and 

- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
the SC UE shall: 

- send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1; and 

- indicate in the SDP offer the full-duplex speech media as removed. 
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12.2.3A Not based on ICS with MSG Server assisted mid-call feature 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8]), if: 

1 . the SC UE is not using ICS capabilities; 

2. the SC UE supports the MSC Server assisted mid-call feature; and 

3. one of the following is true: 

A. there is at least one active PS audio session and the Contact header field received by the SC UE at the 
establishment of the active PS audio session, which has been most recently made active, includes the 
g.Sgpp.mid-call media feature tag as described in annex C; or 

B. there is no active PS audio session and the Contact header field received by the SC UE at the establishment 
of the inactive PS audio session which became inactive most recently includes the g.Sgpp.mid-call media 

feature tag as described in annex C. 

then the SC UE shall apply the MSC Server assisted mid-call feature as follows: 

1. if two or more active PS audio sessions exist, the SC UE shall replace the PS audio components of the two most 
recently active PS audio sessions with the newly established active and held CS voice calls; 

2. if one active PS audio session exists and one or more inactive PS audio sessions exist, the SC UE shall replace 
the PS audio components of the active PS audio session and of the most recently inactive PS audio session with 
the newly established active and held CS voice calls; 

3. if one active PS audio session exists and no inactive PS audio sessions exist, the SC UE shall replace the PS 
audio component of the active PS audio session with the newly established active CS voice call; and 

4. if no active PS audio session exists and one or more inactive PS audio session exists, the SC UE shall replace the 
PS audio component of the inactive PS audio session which became inactive most recently with the newly 
established held CS voice call. 

For each session, the SC UE shall proceed as specified in subclause 12.2.3. 

If two sessions are transferred, the SC UE shall associate the additional transferred session with CS call with transaction 
identifier I and TI flag value as in mobile terminated call. 

NOTE: The active session transaction identifier value is described in 3GPP TS 24.008 [8] 

If a transferred session is with conference focus then the SC UE shall associate the transaction identifiers to participants 
as in subclause 9.2. lA. 

If single inactive session is transferred, the SC UE shall associate the transferred session with CS call with transaction 
identifier and TI flag value as in mobile terminated call. 

12.2.3B Alerting call 
12.2.3B.1 General 

The SC UE shall apply the procedures in subclauses 12.2.3B.3 for access transfer for calls in alerting state if: 

1) the SC UE supports single radio PS to CS access transfer for calls in alerting state; and 

2) there is a single session with at least one dialog that is an early dialog with active audio media where the SC UE: 

- has sent a Contact header field in a SIP INVITE request or 180 (Ringing) response containing the 
g.3gpp.srvcc-alerting media feature tag (as described in annex C); and 

- has received a Record-Route header in a SIP INVITE request or 180 (Ringing) response containing the 
g,3gpp.srvcc-alerting media feature tag (as described in annex C) 

The SC UE shall apply the procedures in subclauses 12.2.3B.4.1 for access transfer for calls in alerting state if: 
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1) the SC UE supports single radio PS to CS access transfer for calls in alerting state; 

2) there are several dialogs supporting more than one session where: 

a) there is at least one dialog supporting a session in the confirmed state with active media; 

b) there is only one session that has at least one dialog that is an early dialog with active audio media where the 
SC UE: 

- has sent a Contact header field in a SIP INVITE request or 180 (Ringing) response containing the 
g.Bgpp.srvcc-alerting media feature tag (as described in annex C); and 

- has received a Record-Route header in a SIP INVITE request or 180 (Ringing) response containing the 
g,3gpp.srvcc-alerting media feature tag (as described in annex C) 

12.2.3B.1 A Considerations for MSG server assisted mid-call feature 

If the SC UE supports both access transfer for calls in alerting state and the MSC server assisted mid-call feature then in 

addition to supporting the procedures specified in subclauses 12.2.3B.3 and 12.2.3B.4.1, it shall apply the procedures 
specified in subclause 12.2.3B.4.2 where there are several dialogs supporting more than one session according to the 
following conditions: 

1) there are no dialogs in the confirmed state with active audio media; 

2) there is at least one dialog in the confirmed state with inactive audio media; 

3) there is only one session that has at least one dialog that is an early dialog with active audio media; and 

4) theSCUE: 

has sent a Contact header field in a SIP INVITE request or 180 (Ringing) response containing both the 
g.3gpp.srvcc-alerting media feature tag and the g.3gpp. mid-call media feature tag (as described in annex C); 

- has received a Record-Route header in a SIP INVITE request or 180 (Ringing) response containing the 
g,3gpp.srvcc-alerting media feature tag ; and 

- has received a Contact header field in a SIP INVITE request or 180 (Ringing) response containing the 
g.3gpp.mid-call media feature tag. 

1 2.2.3B.2 Assignment of Transaction Identifiers to the transferred sessions 

If the SC UE applies the procedures in subclause 12.2. 3B.3 and the SC UE only has a single call in alerting state 
following access transfer, then the SC UE shall associate this session with transaction identifier value and TI flag as 
described in 3GPP TS 24.008 [8]. 

If the SC UE applies the procedures in subclause 12.2.3B.4 and the SC UE has an established session and an additional 

session in alerting state following access transfer, then the SC UE shall associate the transferred session that was in 
alerting state with CS call with transaction identifier 1 and Tl flag value as in mobile terminated call. 

NOTE: For the procedures in subclause 12.2.3B.4.2, the held transaction identifier value is described in 

subclause 12.2.3A as for single inactive session transfer and the active session transaction identifier value 
is described in 3GPP TS 24.008 [8] 

12.2.3B.3 Single call in alerting state 

12.2.3B.3.1 Terminating call in alerting phase 

If these UE: 

- has received a terminating call which is in the early dialog state according to the conditions in subclauses 12.1 
and 12.2.3B.1; and 

- successfully performs access transfer to the CS domain; 
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then the UE continues in Ringing state in CS, i.e. UE moves to Call Received (U7) state as described in 
3GPP TS 24.008 [8]. 

IftheSCUE: 

- has received a terminating call which is in the early dialog state according to the conditions in subclauses 12.1 
and 12.2.3B.1; and 

- has sent a SIP 200 (OK) response (i.e. user answers the call when in the PS domain) prior to successfully 
performing access transfer to the CS domain; 

then the UE sends a CC CONNECT message and transitions to Active (UIO) state as described in 3GPP TS 24.008 [8]. 
12.2.3B.3.2 Originating call in alerting phase 

If the SC UE has initiated an outgoing call which is in the early dialog state according to the conditions in 
subclauses 12.1 and 12.2.3B.1 and the SC UE successfully performs access transfer to the CS domain, then the UE 
continues in Ringing state in CS, i.e. UE moves to Call Delivered (U4) state as described in 3GPP TS 24.008 [8]. 

12.2.3B.4 Established call with a session in alerting state 

1 2.2.3B.4.1 Active session with incoming call in alerting phase 

IftheSCUE: 

has a session with an active speech media component and has received an incoming call (waiting) which is in the 
early dialog state according to the conditions in subclauses 12.1 and 12.2.3B.1; and 

successfully performs access transfer to the CS domain; 

then the UE moves to Call Received (U7) state (defined in 3GPP TS 24.008 [8]) for the incoming call (waiting) (i.e. 
continues in Ringing state in CS for the incoming call waiting). 

12. 2. SB. 4. 2 Held session with new outgoing call in alerting phase 
IftheSCUE: 

has a session with an inactive speech media component and has initiated a new outgoing call which is in the 
early dialog state according to the conditions in subclauses 12.1 and 12.2. 3B.1; and 

- successfully performs access transfer to the CS domain; 
then: 

- the UE moves to Call Dehvered (U4) state (defined in 3GPP TS 24.008 [8]) for the new outgoing call (i,e. UE 
continues in Ringing state in CS for the outgoing call). 

- the UE moves to Call Active (UIO) state (defined in 3GPP TS 24.008 [8]) and Call Held Auxiliary State (defined 
in 3GPP TS 24.083 [43]) for the held call. 

12.2.4 Abnormal cases 
12.2.4.1 Confirmed dialog 

If the SC UE engaged in one or more ongoing IMS sessions and: 

receives a SM NOTIFICATION message containing an "SRVCC handover cancelled, IMS session re- 
estabhshment required" as described in 3GPP TS 24.008 [8] or 3GPP TS 24.301 [52] depending on the access in 
use; or 

- does not successfully retune to the 3GPP UTRAN or 3GPP GERAN after it receives the handover command 
from the eNodeB (as described in 3GPP TS 36.331 [62]) or from the NodeB (as described in 

3GPPTS 25.331 [61]); 
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then the SC UE shall send a SIP re-INVITE request containing: 

1) an SDP offer, including the media characteristics as used in the existing dialog; and 

2) a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" as specified in 
IETF RFC 3326 [57] and with reason-text text set to either "handover cancelled" or "failure to transition to CS 
domain" ; 

by following the rules of 3GPP TS 24.229 [2] in each transferred session. 

12.2.4.2 Early dialog 

If the SC UE is engaged in a session in early dialog state and: 

- receives a SM NOTIFICATION message containing an "SRVCC handover cancelled, IMS session re- 
estabUshment required" as described in 3GPP TS 24.008 [8] or 3GPP TS 24.301 [52] depending on the access in 
use; or 

does not successfully retune to the 3GPP UTRAN or 3GPP GERAN after it receives the handover command 
from the eNodeB (as described in 3GPP TS 36.331 [62]) or from the NodeB (as described in 
3GPPTS 25.331 [61]); 

then if the SC UE the SC UE shall send a SIP UPDATE request containing: 

1) an SDP offer, including the media characteristics as used in the existing dialog; and 

2) a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" as specified in 
IETF RFC 3326 [57], and with reason-text set to either "handover cancelled" or "failure to transition to CS 
domain"; 

by following the rules of 3GPP TS 24.229 [2] in each transferred session. 

12.3 sec AS 

1 2.3.1 sec AS procedures for PS to CS access transfer, SR-VCC 

The sec AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for SR- 
VCC: 

- SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request- 
URI. These SIP INVITE requests originate from the MSC server. In the procedures below, such requests are 
known as "SIP INVITE requests due to STN-SR". 

SIP re-INVlTE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate a CS bearer. In the procedures below, such requests are known as "SIP re-INVITE requests adding ICS 
control". 

- SIP re-lNVlTE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate the port set to "0". In the procedures below, such requests are known as "SIP re-INVITE requests for 
non-ICS control". 

When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg, and the SCC AS does not 
apply MSC Server assisted mid-call feature as described in subclause 12.3.2, the SCC AS shall: 

- follow the PS-CS access transfer procedures specified in subclause 9.3.2 for the session with active full-duplex 
speech component that was most recently made active and the related dialog is in confirmed state; and 

- if the SCC AS supports SRVCC for calls in alerting phase than follow the PS-CS access transfer procedures 
specified in subclause 12.3.4 for the session with active full duplex speech component and the related dialog is in 
early state. 

The SCC AS shall initiate the release for the Source Access Leg only after an operator specific timer has been expired. 
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If the sec AS has sent a SIP 480 (Temporarily Unavailable) response to reject a SIP INVITE request due to STN-SR 

on the Target Access Leg: 

1) if the speech media flow to be transferred was the only media flow in the SIP dialog, the SCC AS shall release 
the remote leg as specified in 3GPP TS 24.229 [2]; or 

2) if the SIP dialog contains other media flows than the active speech flow, the SCC AS shall modify the remote leg 
and remove the speech media flow, as specified in 3GPP TS 24.229 [2]. 

Editor's Note: [TEIIO] Potential overlap and interaction of the above procedure with abnormal case handling 
requires further study. 

When the SCC AS receives a SIP re-INVITE request for adding ICS control, the SCC AS shall follow the procedures as 
described for ICS using Gm in subclause 13.3.2. 

NOTE: When using the ICS controlled CS bearer, only one audio call can be active at a time. Nevertheless, 

several calls can be held in parallel. If the user decides to switch to another (previously held) call, the ICS 
controlled CS bearer is re-used for this call. Therefore no specific procedures for handling of held calls in 
the case of ICS controlled CS bearer are needed. 

When the SCC AS receives a SIP re-INVITE for non-ICS control, the SCC AS shall follow the media removal 
procedures as specified in subclause 13.3.1. 

Unless the MSC Server assisted mid-call feature applies, as only the most recent active audio call is transferred from PS 
to CS audio, the SCC AS shall drop all other previously existing audio session from this UE and indicate them 
accordingly in the SDP Offer sent within SIP re-INVITE requests towards the remote UE. 

1 2.3.2 SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature, SR-VCC 

If 

1. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to static STN, the 
SCC AS local policy requires delaying application of the MSC Server assisted mid-call feature for a time given 
by local policy and the inactive session transfer request has not been received within a time given by local policy 
after the reception of the SIP INVITE request due to static STN; 

2. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to static STN and 
the SCC AS local policy does not require delaying application of the MSC Server assisted mid-call feature for a 
time given by local policy; or 

3. the SC UE did not include the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to static STN; 

then SCC AS shall apply the MSC Server assisted mid-call feature as described in subclause 9.3.2A with the following 
differences: 

1. the SCC AS shall release all the superfluous audio sessions; and 

2. the SCC AS does not initiate release for Source Access Leg of the associated SIP dialogs but remove speech 
media flow for these dialogs. 

Removing speech media flow for SIP dialogs, the SCC AS shall: 

if the speech media flow was the only media flow in the SIP dialogs, release the source access leg as specified in 
3GPPTS 24.229 [2]; or 

if the SIP dialogs contains other media flows than the speech flow, modify the source access leg and remove the 
speech media flow, as specified in 3GPP TS 24.229 [2]. 

If the SCC AS also supports SRVCC for calls in alerting phase then after finishing the procedures of this subclause, the 
SCC AS shall perform the procedures in subclause 12.3.4. 
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1 2.3.3 sec AS procedures for SR-VCC, abnormal case 

1 2.3.3.1 SR-VCC cancelled by MME/SGSN or failure by UE to transition to CS 
domain for ongoing session 

When the SCC AS receives a SIP re-INVITE request containing Reason header field containing protocol "SIP" and 
reason parameter "cause" with value "487" on 

- the original source access leg; or 

- the original source access leg of the additional transferred session if the SCC AS applies the MSC Server 
assisted mid-call feature; 

after having initiated an access transfer that was triggered by a SIP INVITE request due to STN-SR and the SIP 
INVITE request due to STN-SR transaction is not yet completed then the SCC AS shall wait until this transaction has 
completed and then continue with the steps described below. 

When the SCC AS receives a SIP re-INVITE request(s) containing protocol "SIP" and reason parameter "cause" with 
value "487" after having performed an access transfer that was triggered by a SIP INVITE request due to STN-SR, then 
the SCC AS shall: 

1) not release the original access leg once the expiration of the timer described in subclause 12.3.1; and 

2) treat the SIP re-INVITE request(s) as per procedures for removing and adding media as described in 
subclause 13.3.1. 

NOTE: The SCC AS assigns an operator specific timer to delay the release of the Source Access Leg for SR- 
VCC access transfer. 

When the SCC AS receives a SIP response to the SIP re-INVITE request indicating success in removing all media 
components from a dialog that was created due to the SIP INVITE request due to STN-SR then the SCC AS shall send 
a SIP BYE request on this dialog, by following the rules of 3GPP TS 24.229 [2]. 

1 2.3.3.1 A SR-VCC cancelled by IVIIVIE/SGSN or failure by UE to transition to CS 
domain for session in early dialog state 

If the SCC AS apphes the procedures for access transfer for calls in alerting state (as specified in subclause 12.4.3.1), 
then when the SCC AS receives a SIP UPDATE request containing Reason header field containing protocol "SIP" and 
reason parameter "cause" with value "487" on: 

- the original source access leg; or 

- the original source access leg of the additional transferred session if the SCC AS applies the MSC Server 
assisted mid-call feature; 

after having initiated an access transfer that was triggered by a SIP INVITE request due to STN-SR for a session which 
is still in early dialog state the SCC AS shall: 

1) not release the original access leg after the expiration of the timer described in subclause 12.3. 1; 

2) treat the SIP UPDATE request(s) as per procedures for removing and adding media as described in 
subclause 13.3.1; and 

When the SCC AS receives a SIP 200 (OK) response to the SIP UPDATE request, then the SCC AS shall send a SIP 
480 (Temporarily Unavailable) response to reject the SIP INVITE request due to STN-SR. 

If the SCC AS has received a SIP 200 (OK) response from the SC UE prior to receiving the SIP UPDATE request from 
the SC UE, then on receipt of the SIP 200 (OK) response to the SIP UPDATE request sent to the remote UE, the SCC 
AS shall send a SIP 200 (OK) response to the remote UE. Upon receiving the SIP ACK request from the remote UE, 
the SCC AS shall send a SIP ACK request to the SC UE. 
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1 2.3.3.2 P-CSCF releasing the source access leg during SR-VCC 

When sec AS receives a SIP BYE request on the Source Access Leg with the Reason header field containing a SIP 
503 (Service Unavailable) response code then: 

if the sec AS receives a SIP INVITE request due to STN-SR within a time defined by the operator policy after 
the SIP BYE request reception, then the SCC AS shall not initiate release of the Remote Leg; and 

if the SCC AS does not receive a SIP INVITE request due to STN-SR within a time defined by the operator 
policy after the SIP BYE request reception then the SCC AS shall initiate release of the Remote Leg. 

NOTE: 8 seconds is an appropriate value for the operator policy. 

1 2.3.4 SCC AS procedures for PS to CS access transfer when call is in 
alerting phase 

Editor" s Note: [TEIIO] It is currently not decided yet as to whether SRVCC in alerting phase can be supported as 
a standalone feature or whether in addition to the procedures specified in this subclause it requires support 
for MSC-server-assisted mid call feature. Based on that decision, the documentation in subclause 12.3.4 
may need to be restructured so that it is only applicable as part of the MSC-server-assisted-mid-call 
feature. 

12.3.4.1 General 

The SCC AS shall apply the procedures for access transfer for calls in alerting phase as described in subclauses 12.3.4.2 
and 12.3.4.3 if: 

1 . the Contact header field of the SIP INVITE request routed to the SCC AS due to a STN-SR includes the 
g.3gpp.srvcc-alerting media feature tag as specified in annex C; 

2. one of the following is true: 

A. there is only one dialog supporting an SRVCC transferable session with active audio media existing for the 
served user identified in the P-Asserted-Identity header field and the dialog is an early dialog and the Contact 
header field provided by the SC UE includes the g.3gpp.srvcc-alerting media feature tag as described in 
annex C; or 

B. there are several dialogs supporting SRVCC transferable sessions with audio media for the served user 
identified in the P-Asserted-Identity header field such that: 

a. there are one or more early dialogs created by the same SIP INVITE request and the remaining dialogs 
are confirmed dialogs; 

b. all the confirmed dialogs support sessions with inactive audio media; 

c. SCC AS does not apply the MSC server assisted mid-call feature as described in subclause 12.3.2; and 

d. the Contact header field provided by the SC UE at the establishment of the early dialog(s) included the 
g.3gpp.srvcc-alerting media feature tag; 

3. the SCC AS supports the access transfer of calls in alerting state according to operator policy; and 

4. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the transfer calls in alerting phase. 

NOTE 1 : SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id header 
field and the P-Access-Network-Info header field of the SIP REGISTER request. 

The SCC AS shall apply the procedures described in subclauses 12.3.4.4 if: 

1 . the Contact header field of the SIP INVITE request routed to the SCC AS due to a STN-SR includes the 
g.3gpp.srvcc-alerting media feature tag; 

2. the SCC AS supports the access transfer of calls in alerting state according to operator policy; 
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3. the sec AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the transfer calls in alerting phase; and 

NOTE 2: SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id header 
field and the P-Access-Network-Info header field of the SIP REGISTER request. 

4. one of the following is true: 

A. two or more dialogs supporting the SRVCC transferable sessions with audio media exist for the served user 
identified in the P-Asserted-Identity header field such that: 

a. the Contact header fields provided by the SC UE at the establishment of the SRVCC transferable sessions 
included the g.3gpp.srvcc-alerting media feature tag; and 

b. one dialog is a confirmed dialog with active audio media and the remaining dialog(s) are early dialog with 
active audio media created by the same SIP INVITE request; or 

B. two or more dialogs supporting the SRVCC transferable sessions with audio media exist for the served user 
identified in the P-Asserted-Identity header field such that: 

a. the Contact header fields provided by the SC UE at the establishment of the SRVCC transferable sessions 
included the g.3gpp.srvcc-alerting media feature tag; 

b. one dialog is a confirmed dialog with inactive audio media and the remaining dialog(s) are early dialogs 
with active audio media created by the same SIP INVITE request; and 

c. the SCC AS also applies the MSC server assisted mid-call feature as described in subclause 12.3.2. 
Editor's Note: [TEIIO] The exact coding of the feature tag to indicate support for srvcc-alerting is ffs. 

1 2.3.4.2 SCC AS procedures for PS to CS access transfer for terminating call in 
alerting phase using SRVCC procedure 

When the SCC AS applies procedures for access transfer for calls in alerting phase, and receives a SIP INVITE request 
due to STN-SR on the Target Access leg, the SCC AS shall associate the SIP INVITE request with an early dialog 
supporting a session for the user identified in the P-Asserted-Identity header field. 

If the session is a terminating session in early dialog state available for the served user, the SCC AS shall update the 
remote leg by sending a SIP UPDATE request towards the remote UE using the existing established dialog according as 
specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP UPDATE request from the 
remote UE, the SCC AS shall send a SIP 183 (Session Progress) response in response to the SIP INVITE due to STN- 
SR towards the MSC server. 

Upon receiving the SIP PRACK request from the MSC Server, the SCC AS shall send a SIP INFO request towai'ds the 
MSC server as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP INVITE 
request due to STN-SR. The SCC AS shall populate the SIP INFO request as follows: 

1 . include the Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info 
package name; and 

2. include an application/vnd. 3gpp.state-and-event-info H-xml XML body compliant to the XML schema specified 
in the annex D.2 with the state-info XML element containing "early" and the direction XML element containing 
"receiver". 

Upon receiving the SIP INFO request which includes an XML body compliant to the XML schema specified in the 
annex F.1.2 from the MSC Server with the event XML element containing "call-accepted", the SCC AS shall send as 
specified in 3GPP TS 24.229 [2]: 

1) a SIP 200 (OK) response to the SIP INVITE request received earlier from the remote UE indicating that the 
called party has answered the call; and 

2) a SIP 200 (OK) response to the SIP INVITE request due to STN-SR towards the MSC server to indicate the 
successful access transfer. 
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Editor's Note: [TEIIO] Further study is required whether error procedures need to be described. This may be 
required for cases where the SIP INFO request is not received, or for cases were the INFO request 
contains a malformed body. Other error scenrios are INFO request received but not expected. 

Upon receiving the SIP ACK request from the IM CN subsystem, then 

1) if the sec AS had previously received a SIP 200 (OK) response to the dialog that was previously in early state, 
from the SC UE, the SCC AS shall send a SIP ACK request to the SC UE; and 

NOTE 1 : The condition above covers the case where the UE answers the call in the PS domain prior to the 

completion of the handover to the CS domain, whilst the SCC AS is applying the PS to CS access transfer 
procedure specified above, 

2) if the source access leg contains only one audio media components, the SCC AS shall initiate release of the 
source access leg by sending a SIP CANCEL request toward the S-CSCF for sending to the served SC UE. The 
SCC AS shall send the SIP CANCEL request only after an operator specific timer has expired. 

NOTE 2: Delaying the SIP CANCEL request as described above allows an ICS UE to add Gm control if needed 
and an SC UE to reuse the PS dialog in case of SRVCC cancellation. 

If the SCC AS receives a SIP 200 (OK) response to the dialog that was previously in early state, from the SC UE whilst 
the SCC AS is applying the PS to CS access transfer procedure specified above, the SCC AS does not confirm reception 
of the SIP 200 (OK) response with a SIP ACK request and performs no actions on dialogs with the remote party and 
with the MSC server. 

1 2.3.4.3 SCC AS procedures for PS to CS access transfer for originating call in 
alerting phase using SRVCC procedure 

When the SCC AS applies procedures for access transfer for an originating call in alerting phase, and receives a SIP 
INVITE request due to STN-SR on the Target Access leg, the SCC AS shall associate the SIP INVITE request with an 
early dialog or early dialogs related to the originating call for the user identified in the P-Asserted-Identity header field. 

If there is only one early dialog related to the originating call in alerting phase available for the served user, the SCC 
AS shall update the remote leg by sending a SIP UPDATE request towards the remote UE using the existing established 
dialog as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP UPDATE request 
from the remote UE, the SCC AS shall send a SIP 183 (Session Progress) response in response to the SIP INVITE 
request due to STN-SR towards the MSC server. 

If there are more than one early dialogs related to the originating call in alerting phase available for the served user due 
to forking as described in 3GPP TS 24.229[2], the SCC AS shall update the remote legs by sending SIP UPDATE 
requests simultaneously towards every remote UE using the existing established dialogs as specified in 
3GPP TS 24.229 [2]. Upon receiving each SIP 200 (OK) response to the SIP UPDATE request from the remote UE, the 
SCC AS shall send a SIP 183 (Session Progi-ess) response in response to the SIP INVITE request due to STN-SR 
towards the MSC server. 

Upon receiving the first SIP PRACK request from the MSC Server, the SCC AS shall send a SIP INFO request towards 
the MSC server as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP INVITE 
request due to STN-SR. The SCC AS shall populate the SIP INFO request as follows: 

1. include the Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info 
package name; and 

2. include application/vnd. 3gpp.state-and-event-info H-xml XML body containing a XML body compliant to the 
XML schema specified in the annex D.2 with the state-info XML element containing "early" the direction XML 
element containing "initiator". 

Upon receiving the SIP ACK request from the IM CN subsystem, and if the source access leg contains only one audio 
media components initiate release of the source access leg by sending a 404 (Not Found) response toward the S-CSCF 
for sending to the served SC UE. The SCC AS shall send the SIP 404 (Not Found) response only after an operator 
specific timer has expired. 

NOTE: Delaying the SIP 404 (Not Found) response as described above allows an ICS UE to add Gm control if 
needed and an SC UE to reuse the PS dialog in case of SRVCC cancellation. 
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1 2.3.4.4 sec AS procedures for PS to CS access transfer of waiting call 

In order to transfer waiting call, the SCC AS shall send a SIP REFER request according to 3GPP TS 24.229 [2], 
IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP INVITE request due to STN-SR. The 
SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Require header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the additional transferred session SCC AS URI, where the URI also 
includes the following header fields containing the information related to the additional transferred session: 

A. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier 
of an early dialog supporting the SRVCC transferable session of the SC UE; 

B. the Require header field populated with the option tag value "tdialog"; 

C. the To header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted- 
Identity provided by the remote UE during the session establishment; 

D. the From header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted- 
Identity provided by the SC UE during the session establishment; 

E. the Content-Type header field with "application/sdp"; and 

F. the header field with hname "body" populated with an SDP body describing the media streams as negotiated 
in the session with the remote UE; and 

4. application/vnd.3gpp.state-and-event-infoH-xml MIME body with the state-info XML element containing "early" 
and the direction XML element containing: 

A. if terminating call, the "receiver"; and 

B. if originating call, the "initiator". 

1 2.3.5 SCC AS procedures for PS to CS access transfer: SRVCC 
enhancement using ATCF 

The SCC AS needs to distinguish the following initial SIP request: 

- SIP INVITE requests routed to the SCC AS due to ATU-STI in the Request-URI. In the procedures below, such 
requests are known as "SIP INVITE requests due to ATU-STI". 

Upon receiving the SIP INVITE request due to ATU-STI, the SCC AS shall: 

1) if there is a Target-Dialog header field in the SIP INVITE request due to ATU-STI: 

A) determine transferable session set which are all the SRVCC transferable sessions of the SC UE whose private 
user identity is associated with Correlation MSISDN equal to the URI in the P-Asserted-Identity header field 
of the SIP INVITE requests due to ATU-STI; 

Editor's note [eSRVCC, CR#0435]: the term SRVCC transferable session is to be defined. 

B) determine the session being transferred which is a session: 

a) in the transferable session set; 

b) is confirmed dialog; and 

c) with active audio media which has been made active most recently; and 

C) if the session being transferred was determined and is the same as the dialog identifier in the Target-Dialog 
header field in the SIP INVITE request due to ATU-STI, then perform the procedures described for SIP 
INVITE request due to STN-SR in subclause 12.3.1 with the following differences: 
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a) if the SDP offer in the SIP INVITE request due to ATU-STI is the same as the SDP negociated by the 
ATCF in the session being transferred: 

i) do not send SIP re-INVITE request towards remote UE; and 

ii) send a SIP 200 (OK) response to the SIP INVITE request due to ATU-STI containing the SDP 
negotiated by SCC AS towards ATCF in the session being transferred; 

NOTE: handling when no session being transferred is determined or when the dialog identifier in the Target- 
Dialog header field in the SIP INVITE request due to ATU-STI identifies a dialog other than the session 
being transferred is out of scope of this release of this document. 

2) if there is no Target-Dialog header field in the SIP INVITE request: 

a) perform the procedures described for SIP INVITE requests due to STN-SR in subclause 12.3.1. 

Editor's note [eSRVCC]: whether the ATU-STI is static or dynamic needs FFS. 



1 2.4 MSG server enhanced for ICS 

When an MSC server enhanced for ICS supporting SRVCC receives an indication for a session transfer as described in 
3GPP TS 23.216 [49], then the MSC server enhanced for ICS shall initiate a SIP INVITE request and shaU: 

1) set the request URI to the STN-SR for the speech session to be transferred; 

2) set the P-Asserted-Identity header field to the Correlation MSISDN; 

3) set the Contact header field to the address of the MSC server; and 

4) include an SDP offer only containing a speech media component . 

NOTE: MSC servers enhanced for ICS does not apply the ICS procedure described in 3GPP TS 29.292 [18] and 
3GPP TS 24.292 [4] when sending the SIP INVITE request. 

If the MSC server enhanced for ICS supports the MSC server assisted mid-call feature, it shall apply the procedures 
defined in subclause 12.4A. 

After finishing the access transfer procedures, the MSC server enhanced for ICS shall apply the ICS procedure as 
specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4]. 

1 2.4.1 MSC server enhanced for ICS procedures for PS to CS access 
transfer for alerting calls 

The MSC Server shall perform the procedures described in subclause 12.6.3 for the MSC server enhanced for SRVCC 
using SIP interface. 

12.4A MSC server assisted mid-call feature 

An MSC server supporting the MSC server assisted mid-call feature shall apply procedures as described in 
subclause 9.5 with the following modifications: 

NOTE 1 : The MSC server assisted mid-call feature can only be supported by an MSC server enhanced for ICS 
(subclause 12.4) or an MSC server enhanced for SRVCC using SIP interface (subclause 12.6.1). 

0. if the MSC server is enhanced for ICS, the MSC server does not apply the ICS procedure described in 
3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] when sending the SIP INVITE request; 

1 . if two sessions are transferred, associate the SIP INVITE request for an additional inactive session with CS call 
in the Active (NIO) state (as defined in 3GPP TS 24.008 [8]) and in the Call held auxiliary state (as defined in 
3GPP TS 24.083 [43]) with transaction identifier 1 and TI fiag value as in mobile terminated call; and 

NOTE 2: The active session transaction identifier value is described in 3GPP TS 24.008 [8] 
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2. if single session is transferred and all the media in the SDP answer of the SIP 2xx response to the SIP INVITE 
request have directionality inactive, associate the SIP INVITE request for the session with CS call with 
transaction identifier and TI flag value as in mobile terminated call. 

NOTE 3: For an MSG server enhanced for SRVCC using SIP interface, following access transfer, the procedures 
for the handling of transferred conference participants are implementation dependent. 

12.5 EATF 

1 2.5.1 EATF procedures for PS to CS session continuity, E-SR-VCC 

The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionaUty for 
E-SR-VCC: 

1 . SIP INVITE request routed to the EATF due to E-STN-SR in the Request-URI. In the procedures below, such 
requests are known as "SIP INVITE requests due to E-STN-SR". 

NOTE: The same E-STN-SR is used for all the emergency session access transfers within one PLMN. 

Other initial SIP requests can be dealt with in any manner conformant with 3GPP TS 24.229 [2]. 

When the EATF receives a SIP INVITE request due to E-STN-SR on the Target Access Leg, the EATF shall: 

1. associate the SIP INVITE request due to E-STN-SR with a source access leg, i.e. an existing SIP session 
anchored at the EATF with the instance-id media feature tag provided by the SC UE in the Contact header field 
at session establishment equal to the instance-id media feature tag included in the Contact header field of the 
received SIP INVITE request. If no source access leg exists or if multiple source access legs exist, then the 
EATF shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to E-STN- 
SR; and 

2. originate session modification as described in 3GPP TS 24.229 [2] towards the remote UE with a new SDP offer 
with media characteristics as received in the SIP INVITE request due to E-STN-SR. 

Upon receiving the SIP ACK request from the Target Access Leg, the EATF shall release the source access leg as 
described in 3GPP TS 24.229 [2]. 

1 2.6 MSG server enhanced for SRVCC using SIP interface 

1 2.6.1 Session transfer from MSG server enlianced for SRVCC using SIP 
interface 

When an MSC server enhanced for SRVCC using SIP interface receives an indication for a session transfer as described 
in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP interface shall initiate a SIP INVITE 
request and shall: 

1) set the request URI to the STN-SR for the speech session to be transferred; 

2) set the P-Asserted-Identity header field to the Correlation MSISDN; 

3) set the Contact header field to the address of the MSC server; and 

4) include an SDP offer only containing a speech media component. 

If the MSC server enhanced for SRVCC using SIP interface supports the MSC server assisted mid-call feature then in 
addition to the procedures in this subclause it shall apply the procedures defined in subclause 12.4a. 
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1 2.6.2 Emergency session transfer from MSG server enhanced for SRVCC 
using SIP interface 

When an MSC server enhanced for SRVCC using SIP interface receives an indication for a session transfer for an 
emergency session as described in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP 
interface shall initiate a SIP INVITE request and shall: 

1) set the request URI to the E-STN-SR for the speech session to be transferred; 

2) include the instance-id feature tag as specified in IETF RFC 5626 [22] with a value based on the IMEI as defined 
in 3GPP TS 23.003 [12] in the Contact header field; 

3) set the P-Asserted-Identity header field to the Correlation MSISDN if one is available; and 

4) include an SDP offer with media which the MSC server wishes to use in the session. 

12.6.3 MSC server enlnanced for SRVCC using SIP interface procedures 
for PS to CS access transfer for alerting calls 

When an MSC server enhanced for SRVCC using SIP interface supports the PS to CS access transfer for calls in 
alerting state receives an indication for a session transfer as described in 3GPP TS 23.216 [49], then the MSC server 
enhanced for SRVCC using SIP interface shall initiate a SIP INVITE request as described in subclause 12.6.1 and in 
addition it shall populate the INVITE request as follows: 

1. an Accept header field containing the MIME type as specified in annex D.2.3A; 

2. a Contact header field containing the g.3gpp.srvcc-alerting media feature tag as described in annex C; and 

3. a Recv-Info header field containing the g.3gpp.srvcc-alerting package name. 

Editor's Note: [TEIIO] The exact coding of the feature tag to indicate support for srvcc-alerting is ffs. 

Upon receiving a SIP INFO request inside the early dialog created with the SIP INVITE request due to STN-SR, with 
the Info-Package header field containing the g.3gpp. srvcc-alerting; and containing a XML body compliant to the XML 
schema specified in the annex D.2 from the SCC AS with the state-info XML element containing "early" and direction 
XML element containing "initiator", the MSC server enhanced for SRVCC using SIP interface shall enter the Call 
Delivered state (N4) as specified in 3GPP TS 24.008 [8]. The MSC server enhanced for SRVCC using SIP interface 
shall associate this session with transaction identifier value and TI flag as described in 3GPP TS 24.008 [8]. 

Upon receiving a SIP INFO request inside the early dialog created with the SIP INVITE request due to STN-SR, with 
the Info-Package header field containing the g.3gpp. srvcc-alerting; and containing a XML body compliant to the XML 
schema specified in the annex D.2 from the SCC AS with the state-info XML element containing "early" and direction 
set to "receiver", the MSC server enhanced for SRVCC using SIP interface shall enter the Call Received (N7) state as 
specified in 3GPP TS 24.008 [8]. The MSC server enhanced for SRVCC using SIP interface will not generate an in- 
band ring tone towards the calling party. The MSC server enhanced for SRVCC using SIP interface shall associate this 
session with transaction identifier value and TI flag as described in 3GPP TS 24.008 [8]. 

Upon receiving a CS Connect request when in Call Received state as specified in 3GPP TS 24.008 [8], the MSC server 
enhanced for SRVCC using SIP interface shall enter the Active state as specified in 3GPP TS 24.008 [8] and send a SIP 
INFO request inside the dialog created with the SIP INVITE request due to STN-SR for access transfer containing: 

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; 
and 

2. include application/vnd. 3gpp.state-and-event-info H-xml XML body compliant to the XML schema specified in 
the annex D.2 with the event XML element containing "answer" to indicate that the called party has answered 
the call. 

Upon receiving a CS Connect request after having sent the SIP INVITE request due to STN-SR when not yet in Call 
Received (N7) state as specified in 3GPP TS 24.008 [8], the MSC server enhanced for SRVCC using SIP interface will 
store this event. Once a related SIP INFO request inside the associated early dialog, with the Info-Package header field 
containing the g.3gpp. srvcc-alerting; and containing a XML body compliant to the XML schema specified in the 
annex D.2 from the SCC AS with the state-info XML element containing "early" and direction set to "receiver", is 
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received the MSC server enhanced for SRVCC using SIP interface will enter Active (NIO) state as specified in 
3GPP TS 24.008 [8] shall send a SIP INFO request inside the dialog created with the SIP INVITE request due to STN- 
SR for access transfer containing: 

1 . an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; 
and 

2. include application/vnd. 3gpp.state-and-event-info +xml XML body compliant to the XML schema specified in 
the annex D.2 with the event XML element containing "answer" to indicate that the called party has answered 
the call. 

NOTE: Procedmes in the MSC server enhanced for SRVCC using SIP interface how to store and supervise the 
reception of the INFO request are left implementation specific. 

When in Active state as specified in 3GPP TS 24.008 [8], upon receiving a SIP INFO request inside the early dialog 
created with the SIP INVITE request due to STN-SR, with the Info-Package header field containing the g.3gpp.srvcc- 
alerting; and containing a XML body compliant to the XML schema specified in the annex F.1.2 with the state-info 
XML element containing "early" and direction XML element containing "receiver", the MSC server enhanced for 
SRVCC using SIP interface shall send a SIP INFO request inside the dialog created with the SIP INVITE request due to 
STN-SR for access transfer containing: 

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; 
and 

2. include application/vnd. 3gpp.state-and-event-info H-xml XML body compliant to the XML schema specified in 
the annex D.2 with the event XML element containing "answer" to indicate that the called party has answered 
the call. 

Upon receiving a SIP REFER request: 

1 . sent inside the dialog created by the SIP INVITE request due to STN-SR; 

2. with the Refer-Sub header field containing "false" value; and 

3. containing application/vnd.3gpp.state-and-event-infoH-xnil MIME body with the state-info XML element 
containing "early"; 

the MSC server shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request transferring the additional transferred session according to 3GPP TS 24.229 [2] and 
IETF RFC 3515 [13]. The MSC server shall populate the SIP INVITE request as follows: 

A. header fields which were included in the URI in the Refer-To header field of the received SIP REFER 
request as specified in IETF RFC 3261 [19] except the header field with hname "body"; 

B. include in the Contact header field the g.3gpp.srvcc-alerting media feature tag; and 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the header field with hname "body" in the URI in the 
Refer-To header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the header field with 
hname "body" in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the header field with hname 
"body" in the URI in the Refer-To header field of the received SIP REFER request has port with zero 

value; 

NOTE: port can be set to zero or non zero value for the offered "m=" Une whose corresponding "m=" line in the 
header field with hname "body" in the URI in the Refer-To header field of the received SIP REFER 
request has port with nonzero value. 
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3. if application/vnd.3gpp.state-and-event-info+xml MIME body contains direction XML element containing 
"initiator", then enter the Call Delivered state (N4) as specified in 3GPP TS 24.008 [8] for the CS call with 
transaction identifier 1 and TI flag value as in mobile terminated call; and 

4. if application/vnd.3gpp.state-and-event-info+xml MIME body contains direction XML element containing 
"receiver", then enter the Call Received (N7) state as specified in 3GPP TS 24.008 [8] for the CS call with 
transaction identifier 1 and TI flag value as in mobile terminated call. The MSC server will not generate an in- 
band ring tone towards the calling party. 

Upon receiving a CS Connect message with transaction identifier 1 and TI flag value as in mobile terminated call when 
in Call Received state as specified in 3GPP TS 24.008 [8], the MSC server shall send a SIP INFO request inside the 
dialog created by the SIP INVITE request transferring the additional transferred session containing: 

1. an Info-Package header field as specified in draft-ietf-sipcore-info-events [54] with 3gpp.state-and-event info 
package name; and 

2. include application/vnd.3gpp.state-and-event-info+xml XML body compliant to the XML schema specified in 
the annex D.2 with the event XML element containing "call-accepted" to indicate that the called party has 
answered the call. 

Editor's note: [aSRVCC] how to handle race condition of SRVCC access transfer and acceptance/rejection of 
waiting call is EES 

12.7 Access Transfer Control Function (ATCF) 

12.7.1 Distinction of requests 

The ATCE needs to distinguish the following initial SIP requests: 

- SIP INVITE requests containing the STN-SR in the Request-URI and: 
not containing Route header field; or 

containing URI in the topmost Route header field other than the ATCF URI for originating requests and other 
than the ATCF URI for terminating requests. 

In the procedures below, such requests are known as "SIP INVITE requests due to STN-SR". 

1 2.7.2 ATCF procedures for PS to CS access transfer, SR-VCC 

12.7.2.1 General 

Upon receiving the SIP INVITE request due to STN-SR, the ATCF shall: 

1) determine transferable session set which are all the SRVCC transferable sessions associated with C-MSISDN 
equal to the URI in the P-Asserted-Identity header field of the SIP INVITE requests due to STN-SR; and 

Editor's note (WID eSRVCC): it is FES how to determine whether a session is SRVCC transferable session. 

2) determine the session being transferred which is a session: 

A) in the transferable session set; 

B) for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or 
received; and 

C) with active audio media which has been made active most recently. 

12.7.2.2 Active session transfer 

If a session being transferred is determined in subclause 12.7.2.1 and the ATGW anchors the media of the session being 
transferred, the ATCF shall act as B2BUA as describe in subclause 5.6 and shall: 



ETSI 



3GPP TS 24.237 version 10.2.0 Release 10 



66 



ETSI TS 124 237 VI 0.2.0 (2011-04) 



NOTE 1 : At this point, ATCF interacts with ATGW to provide information needed in subsequent bullets. The 
details of interaction between ATCF and ATGW are out of scope of this document. 

1) send 200 (OK) response to the received SIP INVITE request due to STN-SR populated with the SDP answer 
with ATGW ports and IP addresses as provided by the ATGW; 

2) replace the SDP offer in the received SIP INVITE request due to STN-SR with the SDP offer containing the 
currently used media with ATGW ports and IP addresses towards the remote UE as provided by the ATGW; 

3) replace the Request-URI in the received SIP INVITE request due to STN-SR with the ATU-STI associated with 
the session being transferred; 

4) insert Target-Dialog header field with the dialog identifier of the session being transferred; and 

5) forward the request. 

NOTE 2: Upon receiving SDP answer to the SDP offer in the forwarded INVITE request and if the ATGW anchors 

the media of the session being transferred, the ATCF requests the ATGW to start sending and receiving 
media towards the remote UE according to the SDP answer. The details of interaction between ATCF and 
ATGW are out of scope of this document. 

If a session being transferred was determined in subclause 12.7.2.1 and the ATGW does not anchor the media of the 
session being transferred, the ATCF shall act as proxy and shall: 

1) replace the Request-URI in the received SIP INVITE request due to STN-SR with the ATU-STI associated with 
the session being transferred; 

before forwarding the request. 

12.7.2.3 Abnormal procedures 

If transferable session set determined in subclause 12.7.2.1 does not contain any session, the ATCF shall respond with 
404 (Not Found) response. 

1 2.7.2.4 Transfer when only held or alerting session exist 

If the transferable session set determined in subclause 12.7.2.1 is not empty and each session in the transferable session 
set: 

1) is early dialog; or 

2) is confirmed dialog and contains inactive audio media; 

then the ATCF shall provide the proxy role as specified in 3GPP TS 24.229 [2] and shall replace the Request-URI in the 
received SIP INVITE request due to STN-SR with ATU-STI associated with a session in the transferable session set 
before forwarding the request. 



1 3 Roles for media adding/deleting for access transfer 
13.1 Introduction 

This clause specifies the procedures for adding or deleting media to an existing multimedia session. Procedures are 
specified for the SC UE and the SCC AS. 
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13.2 SCUE 

1 3.2.1 Adding or removing media tlirougli Gm 

If the SC UE wants to add or remove media components to a session that was previously estabhshed using Gm 
reference point, the SC UE shall follow the procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If the SC UE wants to transfer media components from the source access leg to an existing target access leg (i.e the 
access legs were previously established due to the partial session transfer) using Gm reference point, the SC UE shall: 

1 . add the media components to the target access leg; and 

2. remove those media components from the source access leg, 

by using procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If SC using ICS is enabled then if the SC UE wants to add or remove CS media components to a session, it shall follow 
the procedures defined in 3GPP TS 24.292 [4]. 

If the SC UE receives a SIP re-INVITE request or a SIP UPDATE request from the remote UE to add or remove media 
components to a session that was previously established using Gm, the SC UE shall: 

follow the procedures defined in 3GPP TS 24.229 [2] for adding or removing PS media; and 

- if SC using ICS is enabled, follow the procedures defined in 3GPP TS 24.292 [4] for adding or removing CS 
media to the session. 

1 3.2.2 Adding Gm control to existing CS session 

The SC UE shall add Gm control to an existing CS session only when SC using ICS is enabled and when there is a 
single full-duplex speech session over CS. If there is more than one full-duplex speech session, the SC UE shall release 
all the ongoing sessions that are not currently active before attempting the procedures described in this section. 

If SC using ICS is enabled and the SC UE wants to add Gm control to an existing CS session that was established 
without Gm, after registering with the IM CN subsystem, the SC UE shall send an initial SIP INVITE request over the 
PS access in accordance with 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows: 

- set the Request-URI to the static STI; and 

- set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. The SC UE can optionally include additional PS media to the SDP in 
accordance to the procedures defined in 3GPP TS 24.229 [2]. 

Upon receiving a SIP 200 (OK) response, the SC UE shall treat the ongoing CS call as estabhshed using Gm and shall 
follow the "ICS UE using Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS call. 

If SC using ICS is enabled and the SC UE receives a new SIP INVITE request containing an audio stream over a 
circuit-switched bearer in the SDP and the SCC AS PSI DN matches the B-party number of the ongoing CS call that 
was estabhshed without Gm, the SC UE shall: 

- respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; and 

treat the ongoing CS call as established using Gm and shall follow the "ICS UE using Gm" procedures defined in 
3GPP TS 24.292 [4] for controlling the CS call. 

13.3 SCC AS 

1 3.3.1 Adding or removing media tlirougli Gm 

If the SCC AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE, in which already existing 
media components of the session are transferred from a source access leg to an already existing target access leg (i.e. 
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the target access leg was already established due to partial session transfer), the SCC AS shall update the remote UE 
using the session transfer procedures defined in subclause 10.3.2. 

NOTE: The SC UE indicates that media is switched from the source access leg to the target access leg by using the 
procedures defined in 3GPP TS 24.229 [2] for adding / removing PS media, i.e. the related connection and port 
information of the transferred media component within the SDP is changed from the source access leg to the target 
access leg. 

If the SCC AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE or remote UE to 
add/remove new media components, to an existing access leg of the session established using Gm, the SCC AS shall 
follow the procedures defined in 3GPP TS 24.229 [2] for adding or removing PS media and shall follow the procedures 
defined in 3GPP TS 24.292 [4] for adding or removing CS media to the session. 

1 3.3.2 Adding Gm control to existing CS session 

If the SCC AS receives a SIP INVITE request containing the static STI in the Request-URI the SCC AS shall determine 
if this SIP INVITE request is for an ongoing call by determining if the received contents of SIP INVITE request's 
Contact header field is bound to an ongoing CS call session identifier. If the SC UE has an ongoing CS call, the SCC 
AS shall: 

respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; 

- treat the ongoing CS call as estabUshed using Gm and shall follow the "SCC AS for service control over Gm" 
procedures defined in 3GPP TS 24.292 [4] for controlling the CS call; and 

- if the SIP INVITE request contains additional PS media, the SCC AS shall send a SIP re-INVITE request 
towards the remote UE, including the newly added PS media, in accordance with the procedures defined in 
3GPPTS 24.229 [2]. 

The SCC AS shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If the SCC AS wants to add Gm control to an existing CS session that was established without Gm, the SCC AS 
shall send a new SIP INVITE request over the PS access in accordance with 3GPP TS 24.229 [2]. The SCC AS shall 
populate the SIP INVITE request as follows: 

- set the Request-URI to the public user identity of the UE; and 

- set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. 

Upon receiving a SIP 200 (OK) response, the SCC AS shall treat the ongoing CS call as established using Gm and shall 
follow the "SCC AS for service control over Gm" procedures defined in 3GPP TS 24.292 [4] for controlhng the CS 
call. 
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14 Void 

1 5 Void 

1 6 Void 

17 Void 

18 Void 

1 9 Void 

20 Service continuity and MMTEL interactions 

20.1 Roles for access tranfer and supplementary services 
interaction 

20.1.1 Introduction 

This subclause describes the SCC AS and SC UE procedures for interaction of access transfer when execution of 
supplementary service as described in 3GPP TS 22.173 [24]. 

20.1.2 Originating Identification Presentation (OIP) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIP besides the 
procedures described in 3GPP TS 24.607 [25]. 

20.1.3 Originating Identification Restriction (OIR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIR besides the 
procedures described in 3GPP TS 24.607 [25]. 

20.1.4 Terminating Identification Presentation (TIP) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIP besides the 
procedures described in 3GPP TS 24.608 [26]. 

20.1.5 Terminating Identification Restriction (TIR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIP besides the 
procedures described in 3GPP TS 24.608 [26]. 

20.1.6 Communication Diversion (CDIV) 

Upon receiving an incoming session split across multiple access legs, if the SC UE desires to invoke the CDIV, it may 
choose any of the PS access legs to invoke the call deflection supplementary service following the procedures described 
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in 3GPP TS 24.604 [27] or the CS access leg to invoke the call deflection supplementary service following the 

procedures described in 3GPP TS 24.072 [42]. 

NOTE: Communication Forwarding unconditional, Communication forwarding on no reply, Communication 
Forwarding on Busy, Conununication Forwarding Not Logged-in and Communication Diversion 
Notification supplementary services are invoked by the CDIV AS as described in 3GPP TS 24.604 [27] 
independent on access type. 

When the SCC AS which is dividing an IMS session into multiple access legs, receives a CDIV request from the SC UE 
on any access leg, the SCC AS shall terminate any other access legs and invoke the CDIV for that access leg according 
to the procedures described in 3GPP TS 24.604 [27]. 

20.1 .7 Communication Hold (HOLD) 

When the SC UE which is dividing an IMS session through multiple access legs, desires to invoke HOLD on one or 
more media componets, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for PS access 
legs, 3GPP TS 24.083 [43] for a CS access leg not controlled by the II interface or 3GPP TS 24.294 [44] for a CS 
access leg controlled by the II interface which contains the affected media components. 

When the SCC AS which dividing an IMS session into multiple access legs, receives a HOLD request from the SC UE 
or remote end on any access leg, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for that 
access leg. 

20.1.8 Communication Barring (CB) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CB besides the 
procedures described in 3GPP TS 24.61 1 [29]. 

20.1 .9 Message Waiting Indication (MWI) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and MWI besides the 
procedures described in 3GPP TS 24.606 [30]. 

20.1.10 Conference (CONF) 

When the SC UE has multiple access legs and if it wants to send any CONF related requests such as SIP SUBSCRIBE 
request or SIP REFER request, the SC UE may send the request on the PS access leg as describes in 
3GPP TS 24.605 [31] or use the procedures described in 3GPP TS 24.294 [44] for a CS access leg controlled by the II 
interface. For a CS access leg without II interface control the procedures in 3GPP TS 24.084 [47] shall be used to create 
and add participants to a conference. 

When the SC UE has multiple access legs and if it receives a request on one of the access legs for CONF service to 
replace an existing session, the SC UE shall: 

- if each access les is PS access leg, follow procedures specified in 3GPP TS 24.605 [31] to establish a new 
session to the conference focus; 

- if the CS access leg is not controlled by the II interface follow the procedures in 3GPP TS 24.008 [8] for 
releasing and establishing a new call towards the conference focus; and 

- if the CS access leg is controlled by the II interface follow the procedures in 3GPP TS 24.294 [44] for establish 
a new session towards the conference focus. 

When the SC UE has multiple access legs and if it receives a request on one the access legs for CONF service to replace 
an existing session outside the dialog, the SC UE shall follow procedures specified in 3GPP TS 24.605 [31] to establish 
a new session to the conference focus. 

When the SC UE has multiple access legs and if the remote UE sends a request for the CONF servive to replace an 

existing session within the same dialog, the SCC AS shall deliver the request for CONF service on the Gm controlled 
any of access legs or over the II interface if II interface control is used or to the CS leg if only a CS leg exists, to the SC 
UE. 
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20.1 .1 1 Explicit Communication Transfer (ECT) 

When the SC UE has multiple access legs and if it acts as the transferor UE, the SC UE may send the request for ECT 
service on any of the PS legs as specified in 3GPP TS 24.629 [32], or on the CS access leg not controlled by the 11 
interface follow the procedures in 3GPP TS 24.091 [46] and on a CS access leg controlled by the 11 interface follow the 
procedures in 3GPP TS 24.294 [44]. 

When the SC UE has multiple access legs and if it acts as the transferee UE, the SCC AS may deUver the request for 
ECT service on any of the access legs. 

NOTE: Delivering of the request towards the CS access leg may be controlled by operator pohcy. 

When the SC UE has multiple access legs and if it receives an ECT request on one of the access legs, the SC UE shall 
foUow the procedures specified in 3GPP TS 24.629 [32] to establish a new session to the Transfer Target. 

20. 1 . 1 2 Advice of Charge (AOC) 

When the AOC service as specified in 3GPP TS 24.647 [33] is active and if the SC UE has multiple access legs, the 
SCC AS may deliver charging information during the communication to the SC UE over any of the access legs which 
accept appUcation/vnd.etsi.aoc+xml MIME type. 

20.1.13 Closed User Groups (CUG) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CUG besides the 
procedures described in 3GPP TS 24.654 [34]. 

20.1.14 Three-Party (3PTY) 

The 3PTY service is considered as a special case of CONE service in 3GPP TS 24.605 [31] and the interaction with 
session transfer is the same as that specified in subclause 20.1.10 for CONE service. 

20.1.15 Flexible Alerting (FA) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and FA besides the 
procedures described in 3GPP TS 24.239 [35]. 

20.1.16 Communication Waiting (CW) 

Upon receiving an incoming session spUt across multiple access legs if the SC UE desires to invoke the CW, it may 
choose any of the access legs to invoke the CW service following to the procedures defined in 3GPP TS 24.615 [36]. 

When the SCC AS which is dividing an IMS session into multiple access legs, receives a CW request from the SC UE 
on any access leg, the SCC AS shall invoke the CW service following the procedures defined in 3GPP TS 24.615 [36]. 

20.1.17 Completion of Communications to Busy Subscriber 
(CCBS)/Completion of Communications by No Reply (CCNR) 

There are no specific procedmes for the SC UE and the SCC AS for interaction of access transfer and CCBS/CCNR 
besides the procedures described in 3GPP TS 24.642 [37]. 

20.1.18 Customized Alerting Tones (CAT) 

There are no specific procedures for the SC UE and the SCC AS for CAT besides the procedures described in 
3GPPTS 24.182 [38]. 
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20.1.19 Malicious Communication IDentification (IVICID) 

When invoking the MCID service in temporary subscription mode and there are multiple active access legs for the 
session, the SC UE may send the SIP re-INVITE request for invoking MCID service as defined in 3GPP TS 24.616 [39] 
on any of the access legs. 

20.1.20 Reverse Charging 

The interaction of the Reverse Charging service according to 3GPP TS 24.647 [33] with access transfer is not specified 
in this version of the specification. 

20.1 .21 Personal Network IVIanagement (PNIVI) 

The interaction of the PNM service according to 3GPP TS 24.259 [40] with access transfer is not specified in this 
version of the specification. 

20.1.22 Customized Ringing Signal (CRS) 

The interaction of the CRS service according to 3GPP TS 24.183 [41] with access transfer is not specified in this 
version of the specification. 

20.2 Void 
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21 Void 
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Annex A (informative): 
Example signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for Service Continuity based on the Session Initiation Protocol (SIP) and 

SIP Events. 

These signalhng flows provide detailed signalhng flows, which expand on the overview information flows provided in 
3GPPTS 23.237 [9]. 

A.2 Introduction 
A.2.1 General 

The signalhng flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [3]. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [3] subclauses 4.1 and 4.2 applies with the additions 
specified below: 

- tel:+l-237-555-llll represents the public user indentity of SC UE A. 

- tel:+l-237-555-2222 represents the public user indentity of UE B. 

- sip:sccasl.homel.net represents the Internet host of SCC AS. 

sip:interUEtransfer@sccasl .homel .net represents the Inter UE Transfer SCC AS URI of the UA A. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [3]. 

However, 3GPP TS 24.228 [3] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [3], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [3] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A.2-1 is used. 
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INVITE 

► SIP message 

SETUP 

► CS message 




Media over a PS connection 



Media over a CS connection 



Figure A.2-1 : Signalling flow notation 

A.3 Signalling flows for registration 
A.3.1 Introduction 

When using CS access for media and to make use of the ISC procedures, the SC UE is registered in IM CN subsystem 
and the signalUng flows are defined in 3GPP TS 24.292 [4] subclause A.2. 

When initiating a CS call, the SC UE can be registered in the CS domain as defined in 3GPP TS 24.008 [8]. 

Whenever the UE acquires IP connectivity via an IP-CAN, the signalling flows for registration in the IM CN subsystem 
are defined in 3GPP TS 24.228 [3]. 

A.3. 2 Signalling flows for multiple registration for service 
continuity 

The signalling flows shown in figure A. 3. 2-1 gives an example when a UE connects to different IP-CAN respectively 
and performs multiple registrations. In this example the UE also supports the Controller UE procedures for lUT 
transfer. In this example the SCC AS receives the registration state information that it needs to implement SCC specific 
requirements from the third-party SIP REGISTER request. 
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UE 



— 1. SIP Register#l- 



P-CSCF#1 



-6. 200 OK- 



9.1JE connects to a 
new IP-CAN 



P-CSCF#2 



I-CSCF 



-2. SIP Register#l- 



-5. 200 OK- 



0. SIP Register#2- 



-15. 401 Unauthorized- 



I 



-16. SIP Register#2- 



-21.200 OK- 



1 1 . SIP 
Register#2 



14. 401 

a 

Unauthorized 

_ 17. SIP 
Register#2 



»20. 200 OK- 



S-CSCF 



3. SIP 
Register#l 
-4. 200 OK- 



_ 12. SIP 

Register#2 
^ 13.401 
Unauthorized 



18. SIP 
Register#2 
-19. 200 OK- 



SCC AS 



-7. SIP Register*- 
•-8. 200 OK— 



-22. SIP Registei* 
^23. 200 OK — 



Figure A.3.2-1 Signalling flows for multiple registrations 

1. SIP REGISTER request (UE to P-CSCF#1)-See example in table A.3.2-1 

UE sends the SIP REGISTER request via the IP-CAN#1. 
NOTE 1: For clarity, the unprotected SIP REGISTER request via the IP-CAN#1 is not shown in this example. 

Table A.3.2-1 SIP REGISTER request (UE to P-CSCF#1) 



REGISTER sip: registrar. homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max- Forwards : 7 

P-Access-Network-Info : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From : <sip : userl_publicl@homel . net > ; tag=4f a3 
To : <sip : userl_publicl@homel . net> 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 13 57 ; comp=sigcomp> ; reg-id=l; +sip . instance="< 
urn : gsma : imei :9042015G-025763-0 >";+g. 3gpp . icsi-ref = "urn%3Aurn-7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . accesstype= "cellularl" ; expires=6000 

; +g . 3gpp . iut -controller 
Call -ID : apb0 3a0s0 9dkjdfglkj4 9111 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 
nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl -MD5 , 
uri= "sip: registrar .homel .net" , response="6629fae49393a05397450978507c4ef 1" 

Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789 ; spi-s=12345678 ; port-c=2468 ; 
port-s=1357 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 

c=8642; port-s=7531 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 2 REGISTER 
Supported: path, outbound, gruu 
Content -Length: 
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2. SIP REGISTER request (P-CSCF#1 to I-CSCF)-See example in table A.3.2-2 

After performing the DNS query, the P-CSCF#1 forwards the SIP REGISTER request towards I-CSCF. The P- 
CSCF adds a Path header field with a flow token and includes the 'ob' parameter 



Table A.3.2-2 SIP REGISTER request (P-CSCF#1 to I-CSCF) 



REGISTER sip: registrar. homel.net SIP/2.0 




Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 




[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 




Max-Forwards: G9 




P-Access-Network-Info : 




Path: <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl .net; lr;ob> 




Require: path 




P-Visited-Network- ID : "Visited Network Number 1" 




P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023551024 " 




From : 




To : 




Contact : 




Call-ID: 




Authorization: Digest username= "userl private@homel.net", realm= " registrar . homel . net " , 


nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl -MD5 , 




uri=" sip: registrar .homel .net" , response= " 662 9f ae493 93a053 97450978507c4ef 1 " 


integrity- 


protected= "yes " 




CSeq: 




Supported : 




Content-Length : 





3. SIP REGISTER request (I-CSCF to S-CSCF) 

The I-CSCF forwards the SIP REGISTER request to the S-CSCF. 

4. SIP 200 (OK) response (S-CSCF to I-CSCF)-See example in table A.3.2-4 

The S-CSCF sends a SIP 200 (OK) response to the I-CSCF indicating that Registration was successful. AS the 
URI in the first Path header field has an "ob" URI parameter, it include a Require header field with the option- 
tag "outbound". 

Table A.3.2-4: SIP 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net ;branch=z 9hG4bK24 Of 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Path : <sip : termOpcscf 1 . visitedl . net ; Ir ; ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From : 
To : 

Call-ID: 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 

pub-gruu= " sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 " 
; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f aj sc7 -aj d6f abzOf 8g5@example . com; gr " 
; +sip . instance= " < urn : gsma : imei :90420156-0257G3-0 >"+g. 3gpp .icsi-ref = "urn%3Aurn- 7%3gpp- 
service . ims . icsi .mmtel " ; +g . 3gpp . ics = "principal " ; +g . 3gpp . access type="cellularl " 
; expires=600000 ; +g . 3gpp . iut -controller 

CSeq: 

Supported: path, outbound 
Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel . net > , <sip : userl_public3@homel . net> , <sip:+l-212- 

555 - lllKShomel . net ; user=phone> 
Content-Length : 



5-6. SIP 200 (OK) response (I-CSCF to UE) 

The I-CSCF forwards the SIP 200 (OK) response to the UE via P-CSCF#1. 
7. SIP REGISTER request (S-CSCF to SCC AS)-See example in table A.3.2-7 
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After UE successfully registered in the IM CN subsystem, the S-CSCF sends a third party SIP REGISTER 
request to the SCC AS based on the initial filter criteria it received. 

Table A.3.2-7: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG499f fhy 
Max-Forwards: 70 

From: <sip : scscf 1 . homel . net> ; tag=538ya 
To : <sip : userl_publicl®homel . net> 
Call-ID: lasdaddlrf jflslj40a222 

P-Access-Network-Info : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Contact: <sip : scscf 1 . homel . net> ; expires=600000 
CSeq: 87 REGISTER 

Content - Type : mult ipart /mixed ; boundary= " boundaryl " 
Content-Length: (...) 

- -boundaryl 

Content-Type: message/sip 

REGISTER sip: registrar. homel. net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Path: <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib®pcscf 1 .visitedl . net ; Ir ,-ob> 
Require: path 

P-Visited-Network- ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
From : <sip : userl_publicl®homel . net > ; tag=4f a3 
To: <sip : userl_publicl®homel . net > 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; reg-id=l; +sip . instance= " < 
urn : gsma : imei :90420156-025763-0>";+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi .mmtel" ; +g . 3gpp . ics= "principal" ;+g . 3gpp . accesstype="cellularl";expires=600000 ; +g . 3gpp . 
iut- controller 

Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 

nonce=base64 {RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 

uri="sip : registrar .homel .net" , response= " 6 62 9f ae4 93 93a0 5 3 974 5 978 5 7c4ef 1 " 

CSeq: 2 REGISTER 

Supported: path, outbound, gruu 

Content-Length: 

- -boundaryl 

Content-Type: message/sip 
SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p .homel .net ;branch=z9hG4bK351g45 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKjiashds7 
Path : <sip : termOpcscf 1 . visitedl . net ; Ir ; ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From : <sip : userl_publicl®homel . net > ; tag=4f a3 
To : <sip : userl_publicl®homel . net> ; tag=3ecl 
Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 

pub-gruu= " sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 0a0c91e6bf6" 

; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f aj sc7-aj d6f abzOf 8g5@example . com; gr " 

; +sip . instance= " < urn : gsma : imei :90420156-025763-0>";+g. 3gpp . icsi-ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics = "principal "+g . 3gpp . accesstype="cellularl " 

; expires=600000 ; +g . 3gpp . iut-controller 

Supported: path, outbound 

Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2®homel . net > , <sip : userl_public3®homel . net > , <sip:+l-212-555- 
llllohomel . net ; user=phone> 
CSeq: 2 REGISTER 
Content-Length: 

- - boundaryl - - 



8. SIP 200 OK response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third party SIP REGISTER request. 
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9. UE connects to a new IP-CAN 

The UE connects to a new IP-CAN and will perform the registration via the new IP-CAN. 

10. SIP REGISTER request (UE to P-CSCF#2)- See example in table A.3.2-10 

UE sends the unprotected SIP REGISTER request via the new IP-CAN to P-CSCF+2 which in this example is a 
different one with previous registration. 

Table A.3.2-10: SIP REGISTER request (UE to P-CSCF#2) 



REGISTER sip: registrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 
Max- Forwards : 70 

P-Access-Network-Info: IEEE-802 . lib 

From: <sip :userl_publicl@homel .net> ; tag=2hiue 

To: <sip:userlj>ublicl@homel .net> 

Contact: <sip : [5555 :: aaa :bbb : ccc : eee] ; comp=sigcomp> ; reg-id=2; +sip . instance= " < 

urn : gsma : imei :90420156-025763-0>;+g. 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 

service . ims .icsi .mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . access type="wlan2";expires=600000 ; + 
g . 3gpp . iut -controller 
Call-ID: E05133BD26DD 

Authorization: Digest username= "userl_private@homel . net " , realm="registrar .homel .net" , 

nonce="", uri= " sip : registrar . homel . net " , response="" 
Security-Client: ipsec-Sgpp; alg=hmac-sha-l-96 ; spi-c=23456789 ; spi-s=12345678 ; port-c=1234 ; 

port-s=5G78 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 1 REGISTER 
Supported: path, outbound, gruu 
Content -Length: 



11-12. SIP REGISTER request (P-CSCF#2 to S-CSCF) 

The P-CSCF forwards the SIP REGISTER request towards S-CSCF via I-CSCF. Likewise in message #2, P- 
CSCF#2 adds a Path header field with flow token and 'ob' parameter. 

13-15. SIP 401 (Unauthorized) response (S-CSCF to UE) 

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 
16-18. SIP REGISTER request (UE to S-CSCF) 

The UE sends the protected SIP REGISTER request towards S-CSCF using contact#2. 
19-21. SIP 200 (OK) response (S-CSCF to UE) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 
22. SIP REGISTER request (S-CSCF to SCC AS) 

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received. 
Table A.3.2-22: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2.0 

Via: SIP/2. 0/UDP scscfl. homel. net;branch=z9hG499ffhy 
Max- Forwards : 70 

From: <sip : scscfl . homel .net> ; tag=538ya 
To: <sip:userl_publicl@homel .net> 
P-Access -Network- Info: IEEE-802 . lib 
Call-ID: lasdaddlrf jf Islj40a222 

Contact: <sip : scscfl . homel . net> ; expires=600000 
CSeq: 87 REGISTER 

Content -Type : multipart /mixed ;boundary= "boundaryl " 
Content -Length: (...) 

- -boundaryl 

Content-Type: message/sip 

REGISTER sip: registrar .homel .net SIP/2.0 
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Via : SIP/2 . 0/UDP pcscf 1 . visitedl . net ;branGh=z9hG4bK24 Of 34 .1, SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : eee] : 13 57 ; Gomp=sigcomp ;branGh=z9hG4bKnashds7 




Max- Forwards : 6 9 




P-Access -Network- Info : IEEE- 8 02 . lib 




Path : <sip :VskztGQ/S8p4WPbOnHbuyh5iJvJIW3ib@pGscf 1 .visitedl . net ; lr;ob> 




Require : path 




P - Vi s i t ed-Net work- ID : "Visited Network Niiinber 1" 




p _ nha ■nri •nrs -\J'^r't dt • i d r\ -\t^ 1 n f^ — " 7\\r-r^t\rJTC\r]m-i-(^C)0 T "rTRI" a'P'r'hRT.cio — 9^RR1 09^." 

It \^lICli_^_LIi^ VCL-.\— . _LL^_L \JL V d _L LLC — Y -L C I— V LJ \J twllLLT^ O \-J ^ J. i_ ± -J UxAIT ±. Jw^nj_l — \J ^ ^ -J -J A-\J ^'-x 




From : <sipii-iserl piibl ic l@hoTnel . net> ; tag=2hiij.e 




To : <sipiu.serl pij.blicl@hoTnel.net> 




Contact I <sip: [5555: :aaa:bbb:ccc:eee] ; coTnp= s iqcoinp > ; req - id=2 ; + sip . instance 


= " < 


urn I gsina i iitie i i 90420156 — 025763 — 0>," +q. 3 gpp - icsi — ref = " urn's 3 Aurn — 7 % 3 gpp ~ 




s ervi ce . iins . icsi . nunt e 1 " ; +q . 3 gpp - ics = "principal" ,* 3 qpp - access type 




= "wlan2";expires = 600000 ; +q . 3qpp . iut-controller 




Call -ID: apb03a0s0 9dkjdfglkj4 9111 




Authorization: Digest username="userl private@homel.net", realm= " registrar 


. homel . net " , 


nonce=base64 {RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 




uri="sip : registrar .homel .net" , response= " 6 62 9f ae4 93 93a0 5 3 974 5 978 5 7c4ef 1 " 




CSeq: 3 REGISTER 




Supported: path, outbound, gruu 




Content-Length: 




- -boundaryl 




Content-Type: message/sip 




SIP/2.0 200 OK 




Via: SIP/2. 0/UDP icscfl p . homel . net ; branch=z9hG4bK351g45 . 1 , SIP/2 . 0/UDP 




pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : eee] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 




Path : <sip : termOpcscf 1 . visitedl . net ; Ir ; ob> 




Service-Route : <sip : origOscscf 1 . homel . net ; lr> 




From: <sip:userl publiclohomel . net> ; tag=2hiue 




To: <sip:userl publiclohomel . net> ; tag=2da87 




Call -ID: apb03a0s0 9dkjdfglkj4 9111 




Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp = sigcomp> ; 




pub-gruu= " sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 


00a0c91e6bf 6" 


; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f a j sc7-aj dGf abzOf 8g5®example . com; gr " 




; +sip . instance= " <urn : gsma : imei :90420156-025763-0>";+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 


service . ims . icsi .mmtel" ; +g . 3gpp . ics= "principal " ; +g . 3gpp . accesstype="wlan2" 




; expires=600000 ; +g . 3gpp . iut-controller 




Supported: path, outbound 




Require : outbound 




Date: Wed, 11 July 2001 08:49:37 GMT 




P-Associated-URI : <sip:userl public2@homel . net> , <sip:userl public3@homel . 


net>, <sip : +1-212-555- 


llllohomel . net ;user=phone> 




CSeq: 3 REGISTER 




Content-Length: 




- -boundaryl- - 





23. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request. 

A.3.3 Signalling flows for registration with SRVCC enhancements 

The signalling flows shown in figure A. 3. 3-1 gives an example flow for UE registration when ATCF is invoked. 
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UE 



P-CSCF 



ATCF 



l-CSCF 



S-CSCF 



sec AS 



HSS 



MME 



8. SIP 401 Unauthorized for SIP REGISTER 



1. SIP REGISTER 

^. 



2. SIP REGISTER 



3. SIP REGISTER 1 

1 ^ 

I 4. SIP REGISTER I 

^ 

5. SIP 401 Unauthorized for SIP REGISTER 



6. SIP 401 Unauthorized for SIP REGISTER 





7. SIP 401 Unauthorized for SIP REGISTER 



9. SIP REGISTER 





110. SIP REGISTER 

>^ 



11. SIP REGISTER! 

>l 



i12. SIP REGISTERi 

>l 

13. SIP'200 OK for SIP REGISTER 





14. SIP 200 OK for SIP REGISTER 

^ 



15. SIP 200 OK for SIP REGISTER 

^ ' 



16. SIP 200 OK for SIP REGISTER 

^ 1 



17. SIP REGISTER 

M 

18. SIP 200 OK for SIP REGISTER 

^ 1 



19. Store STN-SR in HSS 



20. Notify MME that STN- 
SR was changed 



Figure A.3.3-1 registration witli SRVCC enliancements 

1. SIP REGISTER request (UE to P-CSCF) - see example in table A.3.3-1 

UE sends the unprotected SIP REGISTER request to P-CSCF. 



ETSI 



3GPP TS 24.237 version 1 0.2.0 Release 1 82 ETSI TS 1 24 237 V1 0.2.0 (201 1 -04) 

Table A.3.3-1 : SIP REGISTER request (UE to P-CSCF) 



REGISTER sip: homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : eee] ; comp=sigcomp ;branch=z9hG4bKnasiuen8 
Max-Forwards: 70 

P-Access-Network-Info : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From : <sip : userl_publicl@homel . net > ; tag=2hiue 
To : <sip : userl_publicl@homel . net> 

Contact: <sip: [5555: : aaa : bbb : CCC : eee] ; comp=sigcomp> ; +sip . instance = " <urn : gsma : imei : 90420156- 

025763-0>;+g. 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Call-ID: E05133BD26DD 

Authorization: Digest username= "userl_private@homel . net " , realm= "registrar . homel . net " , 

nonce="", uri= " sip : homel . net " , response="" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789 ; spi-s=12345678 ; port-c=1234 ; 

port-s=5678 
Require: sec -agree 
Proxy-Require: sec-agree 
CSeq: 1 REGISTER 
Supported: path, gruu 
Content-Length: 



2. SIP REGISTER request (P-CSCF to ATCF) - see example in table A.3.3-2 

The P-CSCF forwards the SIP REGISTER request towards ATCF. 

Table A.3.3-2: SIP REGISTER request (P-CSCF to ATCF) 



REGISTER sip: homel. net SIP/2.0 

Path : <sip : aga2gf gf Opcscf 1 . visited2 . net : 5070 ;ob> 

Route : <sip : regOatcf . visited2 .net;lr>, <sip:icscf. homel .net ; lr> 

P-Visited-Network- ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi= " 12345 " 
Via: SIP/2. 0/UDP pcscfl . visited2 . net : 5060 ;branch=z9hG4bKnas56565 , SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : eee] ;comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5060 ; received=5555 : : aaa :b 

bb : ccc : eee 
Max-Forwards: 69 
P -Access -Network- Info : 
From : 
To : 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported : 
Content -Length: 



Route: ATCF URI for originating requests (as configured in P-CSCF) followed by URI of the entry point of 
the home network of the UE. 

3.-4. SIP REGISTER request (ATCF towards S-CSCF) - see example in table A.3.3-3 

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER 
request along the Route header fields. 
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Table A.3.3-3: SIP REGISTER request (ATCF towards S-CSCF) 



REGISTER sip: homel.net SIP/2.0 




Path: <sip : termoactf . visited2 .net>; +g. 3gpp . atcf ="tel : +1-237-888- 




9999 " , <sip : aga2gf gf (Spcscf 1 . visited2 . net : 5070 ; ob> 




Route: <sip : icscf . homel . net ; lr> 




P-Visited-Network-ID : 




P-Charging-Vector : 




Via: SIP/2. 0/UDP actf . visited2 . net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2 


0/UDP 


pcscf 1 . visited2 .net : 5 06 ; branch=z9hG4bKnas56565 , SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : eee] ; comp=sigcomp ; branch=z9hG4bKnasiuenB ; rport= 


=5060 ; received=5555 : :aaa:b 


bb : ccc : eee 




Max-Forwards: 68 




P-Access-Network-Info : 




From : 




To : 




Contact : 




Call-ID: 




Authorization : 




Require : 




Proxy-Require : 




CSeq: 




Supported : 




Content-Length : 





Path: ATCF URI for terminating requests followed by P-CSCF URI for terminating requests. The header field 
containing the ATCF URI for terminating requests contains g.3gpp.atcf media feature tag indicating that the 
ATCF role is supported by this URI. The value of the g.3gpp.atcf media feature tag containing the STN-SR 
allocated by ATCF. 

Editor's note: [WID eSRVCC, CR#0350] the insertion of the g.Sgpp.atcf media feature tag is inline with the current 
solution in the draft-holmberg-sipcore-proxy-feature. The actual solution needs to align with the IETF 
accepted solution. 

Route: URI of the entry point of the home network of the UE. 

5-8. SIP 401 (Unauthorized) response (S-CSCF to UE) 

The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 
9. SIP REGISTER request (UE to P-CSCF) - see example in table A.3.3-9 

UE sends the protected SIP REGISTER request to P-CSCF. 

Table A.3.3-9: SIP REGISTER request (UE to P-CSCF) 



REGISTER sip: homel. net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : eee] ;comp=sigcomp;branch=z9hG4bKjiasiuen8 
Max-Forwards: 70 
P-Access-Network-Info : 
From : 
To : 

Contact : 
Call-ID: 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl -MD5 , uri= " sip : homel . net " , 
response="662 9fae493 93a053 9745097B507c4ef 1" 

Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789 ; spi-s=12345678 ; port-c=1234; 
port-s=5678 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 

c=8642; port-s=7531 
Require : 
Proxy-Require : 
CSeq: 2 REGISTER 
Supported : 
Content-Length : 



10. SIP REGISTER request (P-CSCF to ATCF) - see example in table A.3.3-10 

The P-CSCF forwards the SIP REGISTER request towards ATCF. 
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Table A.3.3-10: SIP REGISTER request (P-CSCF to ATCF) 



REGISTER sip: homel.net SIP/2.0 

Path : <sip : aga2gf gf ©pcscf 1 . visited2 . net : 5 070 ; ob> 

Route : <sip : regOatcf . visited2 .net;lr>, <sip:icscf. homel .net ; lr> 
P-Visited-Network- ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value= " AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024 " ; orig- ioi= " 12345 " 
Via: SIP/2. 0/UDP pcscfl.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : eee] ;comp=sigcomp;branch=z9hG4bKnasiuen8 ; rport=5060 ; received=5555 : : aaa :b 

bb : ccc : eee 
Max-Forwards: 69 
P -Access -Network- Info : 
From : 
To : 

Contact : 
Call-ID: 
Authorization : 
Require : 
Proxy-Require : 
CSeq: 

Supported : 
Content -Length: 



Route: ATCF URI for originating requests (as configured in P-CSCF) followed by URI of the entry point of 
the home network of the UE. 

11-12. SIP REGISTER request (ATCF towards S-CSCF) - see example in table A.3.3-11 

The ATCF decides to include itself for sessions created using this registration and forwards the SIP REGISTER 
request. 



Table A.3.3-11 : SIP REGISTER request (ATCF towards S-CSCF) 



REGISTER sip: homel .net SIP/2.0 




Path: <sip:term®actf .visited2 .net> ; +g . Sgpp . atcf= "tel : +1-23 7-888 - 




9999" , <sip:aga2gfgf@pcscf 1 .visited2 .net : 5070;ob> 




Route : <sip : sdvf asdgf 34t4@pcscf 1 . visited2 .net : 5080> 




P-Visited-Network-ID: 




P-Charging-Vector : 




Via: SIP/2. 0/UDP actf .visited2 .net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2 


0/UDP 


pcscf 1 .visited2 .net : 5060 ;branch=z9hG4bKnas56565 , SIP/2 . 0/UDP 




[5555 : : aaa : bbb : ccc : eee] ;comp=sigcomp;branch=z9hG4bKnasiuen8 ;rport= 


=5060;received=5555 : :aaa:b 


bb : ccc : eee 




Max- Forwards : 68 




P-Access -Network- Info: 




From: 




To: 




Contact : 




Call-ID: 




Authorization: 




Require : 




Proxy-Require : 




CSeq: 




Supported: 




Content -Length: 





Path: ATCF URI for ternoinating requests followed by P-CSCF URI for ternainating requests. The header field 
containing the ATCF URI for terminating requests contains g.3gpp.atcf media feature tag indicating that the 
ATCF role is supported by this URI. The value of the g.Bgpp.atcf media feature tag containing the STN-SR 
allocated by ATCF. 

Route: URI of the entry point of the home network of the UE. 
13.-16.SIP 200 (OK) response (S-CSCF to UE) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 
17. SIP REGISTER request (S-CSCF to SCC AS) - see example in table A.3.3-17 

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received. 



ETSI 



3GPP TS 24.237 version 1 0.2.0 Release 1 85 ETSI TS 1 24 237 V1 0.2.0 (201 1 -04) 

Table A.3.3-17: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2 . 

Via: SIP/2. 0/TCP scscf 1 . homel . net ;branch=z9hG499f f hy 
Max- Forwards : 70 

From: <sip : scscf 1 . homel . net> ; tag=538ya 
To : <sip : userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Call-ID: lasdaddlrf jflslj40a222 

Contact: <sip : scscf 1 . homel . net> ; expires=600000 
CSeq: 87 REGISTER 

Content - Type : mul t ipart /mixed ; boundary= " boundaryl " 
Content -Length: (...) 

- -boundaryl 

Content-Type: message/sip 
REGISTER sip: homel. net SIP/2.0 

Path: <sip : termOactf . visited2 . net> ; +g . 3gpp . atcf="tel: +1-237-888- 

9999 " , <sip : aga2gf gf Opcscf 1 . visited2 . net : 5070 ; ob> 
P-Visited-Network- ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value= "AyretyUOdm+602 IrT5tAFrbHLso=023 551024 " ;orig-ioi="1234 5" 
Via: SIP/2. 0/UDP icscf .visited2 .net : 5060 ;branch=z9hG4bKnas8866 ; SIP/2. 0/UDP 

actf . visited2 .net : 5060 ;branch=z9hG4bKnas5889 ; SIP/2 . 0/UDP 

pcscf 1 . visited2 .net : 5060 ;branch=z9hG4bKnas56565 , SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc : eee] ; comp=sigcomp ; branch=z9hG4bKnasiuen8 ; rport=5 060 ; received=5555 : : aaa : b 
bb : ccc : eee 
Max-Forwards: 66 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
From : <sip : userl_publicl@homel . net > ; tag=2hiue 
To : <sip : userl_publicl@homel . net> 

Contact: <sip: [5555: : aaa : bbb : ccc : eee] ; comp=sigcomp> ; +sip . instance="<urn:gsma: imei : 90420156- 
025763-0>;+g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel " 

Call-ID: E05133BD26DD 

Authorization: Digest username="userl_private®homel .net" , realm="registrar .homel .net" , 

nonce="", uri= " sip : homel . net " , response="" 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 2 REGISTER 
Supported: path, gruu 
Content -Length: 

- -boundaryl 

Content-Type: message/sip 
SIP/2.0 200 OK 

Path: <sip: termoactf . visited2 .net>; +g. 3gpp . atcf ="tel : +1-237-888- 

9999 " , <sip : origOactf . visited2 . net > , <sip : aga2gf gf Opcscf 1 . visited2 . net : 5 07 ; ob> 

Via: SIP/2. 0/UDP icscf . visited2 . net : 5 06 ; branch=z9hG4bKnas8865 ; SIP/2. 0/UDP 
actf . visited2 .net : 5060 ;branch=z9hG4bKnas58B9 ; SIP/2 . 0/UDP 
pcscf 1 .visited2 .net : 5060 ;branch=z9hG4bKnas5 65 65 , SIP/2 .0/UDP 

[5555 : : aaa : bbb : ccc : eee] ; comp=sigcomp ; branch=z9hG4bKnasiuen8 ; rport=5 060 ; received=5555 : : aaa :b 
bb : ccc : eee 

Service -Route : <sip : origOscscf 1 . homel . net ; lr> 
From: <sip : userl_publicl@homel . net > ; tag=2hiue 
To : <sip : userl_publicl®homel . net > ; tag=2da87 
Call-ID: E05133BD26DD 

Contact : 

<sip: [5555: : aaa : bbb : CCC : ddd] : 1357 ; comp=sigcomp> ; +sip . instance^ " <urn : gsma : imei : 90420156- 
025763 - 0> "; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
; pub-gruu= " sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 0a0c91e6bf6" 
; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f aj sc7-aj d6f abzOf 8g5@example . com; gr " ; expires=600000 
Supported: path, gruu 

P-Associated-URI : <sip:userl_public2®homel .net>, <sip :userl_public3®homel .net> , <sip:+l-212- 

555-llll@homel .net;user=phone> 
CSeq: 2 REGISTER 
Content -Length: 

- -boundaryl - - 



18. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request. 

19. Store STN-SR in HSS (SCC AS to HSS) 
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sec AS provides the received STN-SR into the HSS to replace the STN-SR pointing to the SCC AS or the 
previously stored STN-SR pointing to other ATCF. 

20. Notify MME that STN-SR was changed (HSS to MME) 

HSS provides the STN-SR to the MME because of the change of the subscription data. 



A.4 Signalling flows for call origination for service 
continuity 

A.4.1 Session origination for CS calls 

An example flow for session origination for CS calls can be found in 3GPP TS 24.292 [4]. 

A.4. 2 Session origination with SRVCC enhancements 

Editor's note: it is EPS how the ATU-STI and C-MSISDN are transported 

Editor's note: it is EES whether the media are anchored in ATGW when the INVITE request is routed through ATCE 
or whether the media are anchored in ATCE later 

The signalling flow shown in figure A.4. 2-1 gives an example of originating session set up when ATCE anchors the 
media of the session. This flow assumes that ATCE was invoked during registration. 
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UE 



P-CSC 



ATCF 



ATGW 



1. SIP INVITE 



2. SIP INVITE 



3. reserve ATGW 
resources 



4. SIP INVITE 



l-CSCF 



S-CSCF 



sec AS 



remote UE 



15. SIP 183 Session Progress for SIP INVITE 



16. configure ATGW 
resources 



17. SIP 183 Session Progress for SIP INVITE 

^ ■ 

. SIP 183 Session Progress for SIP INVITE 

^ 1 



5. SIP INVITE 



6. SIP INVITE 



7. SIP INVITE 



8. invoking further ASs 
according to IPC 



1 1 . response routing to 
invoked ASs 



9. SIP INVITE 



10. SIP 183 Session Progress for SIP INVITE 

^ ■■ ^ 



12. SIP 183 Session Progress for SIP INVITE 

1 ^ 

13. SIP 183 Session Progress for SIP INVITE 

^ 



14. SIP 183 Session Progress for SIP INVITE 



regular continuation of session set up 



Figure A.4.2-1 Signalling flows for service continuity using SRVCC enhancements 

1. SIP INVITE request (UE to P-CSCF) - see example in table A.4.2-1 
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Table A.4.2-1 : SIP INVITE request (UE to P-CSCF) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . visited2 . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P-Pref erred-Identity : "John Doe" <sip : userl_publicl@homel . net> 

P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : <sip : userl_publicl@homel .net> ; tag=17182 8 

To: <tel : +l-212-555-2222> 

Call -ID: Cb0 3a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Supported: precondition, lOOrel, gruu 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 

c=8e42; port-s=7531 
Contact : <sip : userl__publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec - Ild0-a765- 

0a0c91e6bf 6 ; comp=sigcomp> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel " 
Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

0=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : CCC : ddd 
S=- 

c=IN IP6 5555 :: aaa : bbb : CCC : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; maxframes=2 
a=rtpmap:96 telephone -event 



2. SIP INVITE request (P-CSCF to ATCF) - see example in table A.4.2-2 

Since ATCF included a Path header field bound to the registered contact address using which the SIP INVITE request is 
sent, the P-CSCF routes the SIP INVITE request to the ATCF. 



ETSI 



3GPP TS 24.237 version 1 0.2.0 Release 1 89 ETSI TS 1 24 237 V1 0.2.0 (201 1 -04) 



Table A.4.2-2: SIP INVITE request (P-CSCF to ATCF) 



INVITE tel : +1-212-555-2222 SIP/2.0 




Record- Route : <sip : pcscf 1 . visitedl . net ; lr> 




Via : SIP/2 . 0/UDP pcscf 1 . visited2 .net : 5 06 ;branch=z9hG4bKnas56565 , 


SIP/2. 0/UDP 


[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 




Max- Forwards : 69 




Route : <sip : origOatcf . visited2 . net ; lr> , <sip : origOscscf 1 . homel . net 


;lr> 


P-Asserted- Identity : "John Doe" <sip:userl_publicl@homel .net> 




P-Pref erred-Service : 




P -Access -Network- Info: 




Privacy: 




From : 




To : 




t-a±±-±ut 




Cseq : 




Require : 




Supported : 




Proxy-Require : 




Contact : 




Accept -Contact 




Allow: 




Content-Type : 




Content - Length : 




v=0 




o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 




s=- 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 




t = 




m=audio 3456 RTP/AVP 97 96 




b=AS : 25 . 4 




a=curr:qos local sendrecv 




a=curr:qos remote none 




a=des:qos mandatory local sendrecv 




a=des:qos none remote sendrecv 




a=rtpmap:97 AMR 




a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; maxframes=2 




a=rtpmap:96 telephone-event 





Route: ATCF URl for originating requests (as configured in P-CSCF) followed by the remaining Route 
header fields determined by P-CSCF. 

3. ATGW resource reservation 

The ATCF decides to anchor the media of the session and reserves the resources in the ATGW. 

4-9. SIP INVITE request (ATCF towards remote UE) - see example in table A.4.2-4 

The ATCF modifies the SDP offer without changing the dialog identifier and forwards the SIP INVITE request. The 
ATCF replaces the IP address, ports, ... with values provided by ATGW. 
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Table A.4.2-4: SIP INVITE request (ATCF towards remote UE) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Record- Route : <sip : pcscf 1 . visitedl . net ; lr> , < sip : atcf . visited . net ; lr> 
Via: SIP/2. 0/UDP actf .visited2 .net : 5060 ;branch=z9hG4bKnas55889, SIP/2. 0/UDP 
pcscf 1 .visited2 .net : 5 060 ; branch=z9hG4bKnas56565 , SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route : <sip : origOscscf 1 . homel .net ; lr> 

P- Asserted- Identity : 

P-Pref erred-Service : 

P -Access -Network- Info : 

Privacy: 

From : 

To : 

Call-ID: 
Cseq : 
Require : 
Supported : 
Proxy-Require : 
Contact : 
Accept -Contact 
Allow : 

Content-Type : 
Content -Length : 

v=0 

o=- 22 333 IN IP6 8888 :: 111 : 222 : 333 : 444 
s = - 

C=IN IP6 8888 :: 111 : 222 : 333 : 444 

t = 

m=audio 8899 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; maxframes=2 
a=rtpmap:96 telephone -event 



SDP offer: the IP address and ports are updated to contain the values provided by ATGW . 

10-12. SIP 183 (Session Progress) response (remote UE towards SCC AS) 
The remote UE responds with SIP 183 (Session progress) response. 

13.-15.SIP 183 (Session Progress) response (SCC AS towards ATCF) - see example in table A.4.2-13 
The SCC AS forwards the SIP 183 (Session progress) response. 
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Table A.4.2-13: SIP 183 (Session Progress) response (SCO AS towards ATCF) 



SIP/2.0 183 Session Progress 

Record- Route : <sip : pcscf 1 . visitedl . net ; lr> , < sip : atcf . visited . net ; lr> , 

<sip:scscf. homel .net;lr>, <sip:icscf. homel . net ; lr> , <sip : sccas . homel . net ; lr> 

Via: SIP/2. 0/UDP sccas. homel. net:5060;branch=z9hG4bKnas522, SIP/2. 0/UDP 
scscf .homel .net : 5060 ; branch=z9hG4bKnas889 , SIP/2 . 0/UDP 
icscf .homel .net : 5060 ;branch=z9hG4bKnas225 , SIP/2 . 0/UDP 
actf . visited2 .net : 5060 ;branch=z9hG4bKnas55889 , SIP/2 . 0/UDP 
pcscf 1 .visited2 .net : 5 060 ; branch=z9hG4bKnas56565 , SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 60 

P- Asserted- Identity: <tel : +1-212 -555 -2222 > 

Privacy : 
From : 

To: <tel:+l-212-555-2222>; tag=aaa 

Call-ID: 

Cseq : 

Require : 

Supported : 

Contact : <sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 
ad7 6cc7f c74> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow : 

Content-Type : 
Content -Length: 

v=0 

0=- 462346 5654 IN IP6 1234 : : 55 : 66 : 77 : 88 
S=- 

C=IN IP6 1234 : : 55 : 66 : 77 : 88 

t = 

m=audio 4456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local none 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; maxframes=2 
a=rtpmap:96 telephone -event 



16. ATGW resource configuration 

The ATCF confi 2ures the resources of ATGW. 

17. SIP 183 (Session Progress) response (ATCF towards UE) - see example in table A.4.2-17 

The ATCF replaces the IP address, ports, ... in SDP answer with values provided by ATGW. 
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Table A.4.2-17: SIP 183 (Session Progress) response (ATCF towards UE) 



SIP/2.0 183 Session Progress 

Record- Route : <sip : pcscf 1 . visitedl . net ; lr> , < sip : atcf . visited . net ; lr> , 

<sip:scscf. homel .net;lr>, <sip:icscf. homel . net ; lr> , <sip : sccas . homel . net ; lr> 

Via: SIP/2. 0/UDP pcscfl.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 60 

P- Asserted- Identity: <tel : +1-212 -555 -2222 > 
Privacy : 
From : 
To : 

Call-ID: 
Cseq : 
Require : 
Supported : 

Contact : <sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 
ad7 6cc7f c74> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow : 

Content-Type : 
Content -Length : 

v=0 

o=- 44 555 IN IP6 8 8 8 8 :: 111 : 222 : 333 : 444 
s = - 

C=IN IP6 8888 :: 111 : 222 : 333 : 444 

t = 

m=audio 11234 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local none 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; maxframes=2 
a=rtpmap:96 telephone -event 



SDP answer: the IP address and ports are updated to contain the values provided by ATGW. 



A.5 Signalling flows for call termination for service 
continuity 

A.5.1 Session termination using CS media 

An example flow for session termination using CS calls can be foimd in 3GPP TS 24.292 [4]. 



A.6 Signalling flows for PS-CS access transfer 
A.6. 1 PS-CS access transfer: CS-PS 

In this example, SC UE A has an ongoing session with remote UE B over CS bearer before access transfer. When SC 
UE connects to an IP-CAN, it decides to transfer the session over the new IP-CAN. 
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Figure A.6.1-1 : Signalling flow for PS-CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SC UE A has an ongoing session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the session over the new IP-CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) - see example in table A.6.1-3 

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing caU. 
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Table A.6.1-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain .xferOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route: <sip : pcscfl . homel . net : 7531 ; Ir >, <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID: Cb0 3a0s09a2sdfglkj4 902 3 7 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 

Contact : <sip : userl_publicl@homel . net ; gr= urn : uuid: f 81d4f ae- 7dec- lld0-a765- 
00a0c91eGbfG>,•+g. 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp ; application/3gpp- ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s= 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate EM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iPC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities)- See example in table A.6.1-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request.The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 
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Table A.6.1-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip : userlpubliclohomel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; Ir > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl®homel . net> ; tag=1717777 

To: <tel : +l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 
adVSccVf c74 > ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
17. Media paths between UE A and UE B 

The media path is using the new IP-CAN. 
18-19. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 

20-22. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 
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23-24. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate EM CN subsystem entities) 

A.6.2 PS-CS access transfer: PS-CS 

In this example, SC UE A has an ongoing session with remote UE B over PS bearer before access transfer which is 
anchored at SCC AS. When the SC UE attaches to the CS domain, it decides to transfer the session over the CS bearer 
without ICS capability. 
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Figure A.6.2-1 Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A is on an active session with UE B: 

There is an ongoing IP bearer between the SC UE and the remote end UE B. The call is achored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the session over the CS bearer. 
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3. CC SETUP messages 

The SC UE sends the CC SETUP message with the static STN as the called party number. 

4. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
table A.6.2-4 

Table A.6.2-4: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 .homel .net;branch=z9hG4bk731b87 
Max- Forwards : 70 

Route : <sip : icscf 1 . homel . net ; lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 
Privacy: none 

From: <tel: +l-237-555-llll> ; tag=171828 
To: <tel: +l-237-555-3333> 
Call-ID: Cb03a0s09a2sdfglkj490333 
Cseq: 12 7 INVITE 

Supported: lOOrel, precondition 

Accept -Contact : * ; +g. 3gpp. icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
P-Asserted-Service : urn:urn-7 : 3gpp-service . ims . icsi .mmtel 

Contact : <sip :mgcf 1 . homel .net ;gr> ; +g . 3gpp . icsi-ref = "urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 
t=0 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des : qos mandatory local sendrecv 
a=des : qos none remote sendrecv 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.6.2- 
8 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.6.2-8: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip : user2publicl@home2 . net ;gr=urn : uuid : 2ad8 950e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf = [5555: :b9 9:c88:d7 7:eee] ; ccf = [5555: :a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value= "BzyretyU0dm+6O2IrT5tAFrbHLso=023551034 " ; orig- 

ioi= " type3homel . net " 
Privacy: none 

From: <tel : +1-23 7 - 555 - 1111> ; tag=569812 
To: <tel :+l-237-555-2222>; tag=26545 
Call- ID: ddl3a0s09a2sdfglkj490378 
Cseq : 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: 

Content-Type: Content-Length: 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 

t = 

m=audio 3456 RTP/AVPF 97 96 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 
m=message TCP/MSRP 98 
a=accept- types : text/plain 



9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 
Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to interworldng entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

16. CC CONNECT message (interworldng entities to SC UE A) 

17. CC CONNECT ACKNOWLEDGE message (SC UE A to interworking entities) 
18-19. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 
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The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearer is still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP-CAN, by sending a SIP BYE request to 
the UE A. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate EM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A rehnquishes all resources pertaining to the old IP-CAN. 

25. Media paths between SC UE A and UE B 

Finally, the session is transferred from PS bearer to CS bearer. 



A.7 Signalling flows for PS-PS access transfer 
A. 7.1 Introduction 

The signalhng flows for PS-PS access transfer demonstrate how a multimedia session is transferred from Source Access 
Leg to the Target Access Leg. The following signalling flows are included: 

- subclause A.7. 2 shows an example when all media of an ongoing communication session and the associated 
signalhng are transferred from Source Access Leg to the Target Access Leg; and 

- subclause A.7. 3 shows an example when not all media of an ongoing communication session are transferred 
from the Source Access Leg to the Target Access Leg. 



A.7.2 PS-PS access transfer with full media transfer 

The signalling flows shown in figure A. 7. 2-1 describes the PS-PS access transfer procedure when all media of an 
ongoing communication session and the associated signalling are transferred from one contact address of an UE to a 
different contact address of the same UE. No lower-level mechanism to support the access transfer is assumed or 
needed. 

In this example the UE-1 is on an active multimedia session with the UE-2 via one IP-CAN. After changing to a new 
IP-CAN, obtaining a new IP address, and discovering a P-CSCF, the UE-1 reserves resources in new IP-CAN prior to 
initiating the PS-PS access transfer procedure. When the PS-PS access transfer procedure is completed, the UE-1 
continues the multimedia session with the UE-2 on the new IP-CAN. In this example, when attaching to the new IP- 
CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that the UE-1 and the IM CN subsystem support simultaneous multiple 
registrations and requires that the UE-1 supports dual mode operation. 

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of 
the Call-ID, From tag, and To tag. 
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Figure A.7.2-1 : Signalling flow for session handover 

NOTE 3: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. UE-1 is on an active session with UE-2 

The UE-1 is in an active session with the UE-2. The call is anchored in the SCC AS. It is irrelevant which 
endpoint initiated the caU. Each caU leg is uniquely identified with a respective dialog identifier. The caU leg 
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over old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. The UE-1 and UE-2 exchange media over the old IP-CAN, which is maintained while the UE-1 
initiates the handover procedure. 

2. UE-1 connects to new IP-CAN 

The UE-1 determines that a handover of the session is required. The UE-1 connects to the new IP-CAN. The 
UE-1 obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate EM CN subsystem entities over new IP-CAN 

The UE-1 registers with the S-CSCF over the new IP-CAN using the standard multiple registrations procedure. 
Depending on the UE-1 configuration, the discovery of the P-CSCF in the new IP-CAN can precede this. 

4. UE-1 acquires resources in new IP-CAN 

Based on the UE-1 and new IP-CAN capabilities, the UE-1 decides to use the same codec that was used over the 
old IP-CAN. The UE-1 reserves resources (e.g. QoS) in the new IP-CAN that will be needed for the signalling 
and transferred media, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate EM CN subsystem entities) - see example in table A.7.2-5 

The UE-1 sends initial SIP INVITE request with a new SDP offer to the UE-2 that indicates that the new call 
replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and specifies in the 
SDP the new contact address that will be used for media over the new IP-CAN. Upon sending the initial SIP 
INVITE request, the UE-1 is ready to receive the RTP packets either over the new IP-CAN or the old IP-CAN. 
The RTP packets can arrive over the new IP-CAN prior to the UE-1 receiving the SIP 200 (OK) response for the 
initial SIP INVITE request. 

Table A.7.2-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max - Forwards : 7 

Route : <sip :pcscf 1 . homel .net : 7531 ; Ir ; comp=sigcomp> , <sip : orig@scscf 1 .homel .net ; lr> 
P-Pref erred-Identity: "John Doe" <sip:userl_publicl@homel .net> 
P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip : userl_publicl@homel .net> ; tag=171828 

To: <tel : +l-212-555-2222> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, outbound 
Require: sec -agree; replaces 

Replaces: me03a0s0 9a2sdf gj kl491777 ; to-tag=774321 ; f rom-tag=64727891 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91e6bf 6 ; 

ob> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " ; +g . 3gpp . ics= "principal " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s=- 

C=IN IP6 5555 :: aaa :bbb : ccc :ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 
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Require: the "replaces" option tag indicate that the support for Replace header field is required. 
Replaces: specifies the existing call that will be replaced with the new call. 

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that the 
resources in the new IP-CAN have been acquired. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate EM CN subsystem entities to SCC AS) - see example in table A.7.2-7 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The P-CSCF added a Record-Route header field with a flow token to ensure that mid-dialog SIP 
requests are forwarded to the UE-1 over the correct flow. The SCC AS acts as a routeing B2BUA as specified in 
3GPP TS 24.229 [2]. The SCC AS includes the contents of the Contact header field from the received SIP 
INVITE request. 

Table A.7.2-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .homel .net;branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; compos igcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 67 

Route : <sip:sccas. homel . net ; lr> ; <sip : cb0 3aOs0 9a2sdf glkj 4 90333®scscf 1 . homel . net ; lr> ; orig- 

dialog-id="0: 73 935718_92 645110 -712 786 jd2463 953 02d-zKE" 
Record-Route: <sip : scscf 1 . homel . net ; lr> , <sip: 

GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@pcscfl .homel .net ; lr> 
P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net > , <tel : +l-212-555-llll> 
P- Access -Network- Info : Privacy : Require : replaces 

P- Charging- Vector : icid-value= " AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig- 
ioi=type3ashomel .net> 

P- Charging- Function- Addresses : ccf = [5555 : : b99 : c8 8 : d77 : e66] ; ccf = [5555 : : a55 :b44 : c33 : d22] ; 

ecf = [5555: :lff:2ee: 3dd:4ee] ; ecf = [5555 : : 6aa: 7bb: Sec : 9dd] 
From: <sip :userl_publicl®homel . net> ; tag=171828 
To: <tel:+l-212-555-2222> 
Call-ID: 
Cseq : 

Supported : 

Replaces : 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length: (...) 

v= 
o= 

s = 

c- 

t = 

m= 

b= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 



8. Remote leg update 

The SCC AS based on the content of the Replaces header field correlates the initial SIP INVITE request to the 
existing local and remote call legs of the existing concatenated end to end session between the UE-1 and UE-2. 
The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing the new 
SDP offer that it has received from the UE- 1 . 
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9. SIP re-E^TVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.2-9 

The UE-2 is informed of the change in access leg by the SCC AS sending a SIP re-INVITE request to the S- 
CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE-1 (Step 5). 

Table A.7.2-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip:user2 j)ublicl@home2 .net ; gr=urn :uuid: 2ad8950e-48a5-4a74 -8d99-ad76cc7f c74> SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max- Forwards : 67 

Route : <scscf 1 . homel .net ; lr> , <sip : scscf 2 . home2 .net ; lr> , <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted-Identity : P-Access -Network- Info : Privacy : P- Charging- Vector : icid- 

value="BzyretyU0dm+6O2IrT5tAFrbHLso=023 551034 " 
P-Charging-Function-Addresses : 

From: <sip:userl_publicl@homel .net>; tag=1717777 

To: <tel:+l-212-555-2222>, tag=4321 

Call-ID: dcl4bltl0b3teghmlk5013333 

Cseq: 111 INVITE 

Supported: 

Contact : < sip : user l_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6 ;ob>; +g. 3gpp. icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Allow: Accept: application/sdp 
Content -Type : 
Content -Length: (...) 

v=0 

0=2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 
s=- 

c= IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS:25.4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des : qos mandatory local sendrecv 

a= des: qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a= rtpmap:96 telephone -event 
a= maxpt ime : 2 



Route: The SIP re-INVITE request contains the saved Ust of Route header fields that the SCC AS has saved for 
the remote leg of the call. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) - see example in table A.7.2-10 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 
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Table A.7.2-10: SIP re-INVITE request (intermediate liVI CN subsystem entities to intermediate IM CN 

subsystem entities) 



INVITE < sip :user2_publicl®home2 . net ; gr=urn :uuid: 2ad8950e-4 8a5-4a74 - 8d99-ad76cc7f c74 > SIP/2.0 
Via: SIP/2. 0/UDP scscfl.homel. net ;branch=z9hG4bK240f 34.1, SIP/2. 0/UDP sccas.homel.net; 

branch= z 9hG4bK3 3 2b3 3 . 3 ; 
Max-Forwards: 66 

Route : <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 

P-Asserted- Identity: 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq : Supported: Contact : <sip :userl_publicl®homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel " 
Contact : 
Allow: 
Accept : 

Content -TypeContent -Length : 

v= 

o= 

s=- 

c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards the UE-2 by the intermediate IM 
CN subsystem entities. 

12. Media paths between UE-1 and UE-2 

The UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that the UE-1 is ready to 
receive the same media on a different contact address. Since the UE-2 has resources already available, it starts to 
send the media to the UE-l's contact address specified in the SDP offer immediately. 

The UE-1 will be receiving the RTP packets over new IP-CAN. However, the UE-1 can receive some out-of- 
sequence RTP packets over the old IP-C/^. The RTP packets are delivered to the codec in sequence. Once the 
UE-1 determine that no media will be received over the old IP-CAN (e.g. by examining the sequence numbers in 
the RTP headers), it can reUnquish the resources that it has been using for incoming media on the old IP-CAN. 

The UE-1 sends the media to the UE-2 over the old IP-CAN. 

Resources used for signalling on the old IP-CAN are not released. 

13. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-lNVlTE request containing the SDP offer, since the UE-2 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 
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16. SIP ACK request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

17. SIP ACK request (intermediate IM CN subsystem entities to intermediate EM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

18. SIP ACK request (intermediate EM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the UE- 
2. 

19. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header field that was received in the initial SIP INVITE request 
(step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP 200 (OK) response to the 
initial SIP INVITE request contains the SDP answer that is identical to the SDP answer that the SCC AS has 
received in the SIP 200 (OK) response to SIP re-INVITE request from the UE-2 (Step 13). 

20. SIP 200 (OK) response (intermediate EM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the UE-1. 

21. Media paths between UE-1 and UE-2 

The UE-1 receives the SIP 200 (OK) response containing the SDP answer that indicates that the UE-2 is ready to 
receive media. Since the UE-1 has already resources available, it starts to send media over new IP-CAN to the 
UE-2's contact address specified in the SDP answer immediately. 

The UE-1 can relinquish the resources that it has been using for outgoing media on the old IP-CAN. 
Resources used for signalling on the old IP-CAN are not released. 

22. SIP ACK request (UE-1 to intermediate EM CN subsystem entities) 

The UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

23. SIP ACK request (-intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

24. SIP BYE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN, by sending a SIP BYE request to 
the UE-1. 

25. SIP BYE request (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP BYE request to the UE-1. 

26. SIP 200 (OK) response (UE-1 to intermediate EM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the UE-1 sends a SIP 200 (OK) response over the old 
IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP -CAN. 

27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 
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Since both the old contact address and the new contact address were registered using muhiple registrations procedure 
with different reg-id values, then upon transferring the dialog from the old contact address to the new contact address, 
the UE-1 is still registered with the old contact address and the UE-1 subscription dialog to its reg-event using the old 
contact address is intact. 

A.7.3 PS-PS access transfer with partial media transfer 

The signalling flows shown in figure A.7.3-1 describes the PS-PS access transfer procedure when not all media of an 
ongoing communication session are transferred from the Soiu'ce Access Leg to the Target Access Leg. No lower-level 
mechanism to support the access transfer is assumed or needed. 

In this example, UE-1 is on an active multimedia session with UE-2 via one IP-CAN. After connecting to an additional 
IP -CAN, obtaining an additional IP address, discovering a P-CSCF, and performing registration in the IM CN 
subsystem, UE-1 reserves resources in the new IP-CAN prior to initiating the PS-PS access transfer procedure. When 
the PS-PS access transfer procedure is completed, UE-1 continues the multimedia session with UE-2 on both the old 
and the new IP-CANs. In this example, when attaching to the new IP-CAN, it is irrelevant whether the UE-1 uses the 
same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that UE-1 and the IM CN subsystem support simultaneous multiple registrations 
and requires that UE-1 supports dual mode operation. 
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Figure A.7.3-1 : Signalling flow for PS-PS session transfer with partial media transfer 

NOTE 2: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

UE-1 is in an active session with UE-2. The call is anchored in the SCC AS. It is irrelevant which endpoint 
initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg over IP- 
CAN #1 is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. UE-1 and UE-2 exchange media over the IP-CAN #1, which is maintained while the UE-1 initiates 
the session transfer procedure. 



2. UE-1 connects to IP-CAN #2 
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UE-1 connects to the new IP-CAN and obtains an IP address that it will use for the signalling and media. 

3. UE-l registers with intermediate EM CN subsystem entities over IP-CAN #2 

UE-1 registers with the S-CSCF over the IP-CAN #2 using the standard multiple registrations procedure. The P- 
CSCF in the signalhng path of this registration can be distinct from the one used in the signalling path over IP- 
CAN #1. 

4. UE-1 acquires resources in IP-CAN #2 

UE-1 decides to perform partial media transfer to the IP-CAN #2. Based on UE-1 and IP-CAN #2 capabilities, 
the UE-1 decides to use the same codec that was used over the IP-CAN #1 for the media components to be 
transferred. UE-1 ensures that the resources (e.g. QoS) in IP -CAN #2 that will be needed for the signalling and 
transferred media are available, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate EM CN subsystem entities) - see example in table A.7.3-5 

UE-1 sends initial SIP INVITE request with a new SDP offer to UE-2 and indicates that the video component is 
to be transferred to IP-CAN #2. The initial SIP INVITE request establishes a dialog for signalling and specifies 
in the SDP new contact address that will be used for media over IP-CAN #2. Upon sending the initial SIP 
INVITE request, UE-1 is ready to receive the RTP packets over both IP-CAN #1 and IP-CAN #2. 

Table A.7.3-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb: ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 70 

Route : sip:pcscf 1 .homel .net : 7531 ; Ir ; comp=sigcomp> , <sip : orig@scscf 1 .homel .net ; lr> 
P-Pref erred-Identity : "John Doe" <sip:userl_publicl@homel .net> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

From: <sip:userl_publicl@homel .net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call-ID: Cb03a0s09a2sdfglkj490333 
Cseq: 12 7 INVITE 

Supported: lOOrel, precondition, gruu, outbound 
Require: sec-agree; tdialog 

Target -Dialog: me03a0s09a2sdf gjkl491777 ; remote- tag=77432 1 ; local-tag=64727891 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 

Contact : < sip : user l_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6 ;ob>; +g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp . ics= "principal" ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=audio RTP/AVP 97 96 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
m=video 3400 RTP/AVP 98 99 
b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des : qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required. 
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Target-Dialog: specifies the existing call that will be transferred. 

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that only the 
video component will be transferred and the resources in the new IP-CAN have been reserved. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The P-CSCF added a Record-Route header with a fiow token to ensure that mid-dialog SIP 
requests are forwarded to the UE-1 over the correct flow. The SCC AS acts as a routeing B2BUA as specified in 
3GPPTS 24.229 [2]. 

8. Remote leg update 

Based on the content of the Target-Dialog header field, the SCC AS correlates the SIP INVITE request for 
session transfer to the existing local and remote call legs of the existing concatenated end to end session between 
UE-1 and UE-2. The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the remote UE- 
2 containing the new SDP offer based on the partial media transfer request received from UE-1 and the 

negotiated SDP for the original session. 

9. SIP re-INVITE request (SCC AS to intermediate EM CN subsystem entities) - see example in table A.7.3-9 

UE-2 is informed of the change in access leg by the SCC AS sending a re-INVITE request to the S-CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request.The SIP re-INVITE 
request contains the SDP offer that is based on original SDP offer and the SDP offer that the SCC AS received in 
the initial SIP INVITE request from the UE-1 (Step 7). 
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Table A.7.3-9: SIP re-INVITE request (SCC AS to intermediate IIUl CN subsystem entities) 



INVITE < sip : user2 publicl@home2 . net ;gr=urn : uuid : 2ad8 950e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 0> 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 70 

Route: <scscf 1 . homel . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted-Identity: "John Doe" <sip:userl_publicl@homel .net>, <tel : +1-212 -555-llll> 

Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " 

P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel : +l-212-555-2222>, tag=4321 

Call-ID: dcl4bltl0b3teghmlk5013333 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lld0-a765- 
00a0c91e6bf 6 ; ob> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

0=2987933100 2987933101 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = - 
t = 

m=audio 3456 RTP/AVP 97 96 
c=IN IP6 5555 :: aaa :bbb : ccc : eee 
b=AS : 25 . 4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a= rtpmap:96 telephone-event 

a= maxptime:20 

m=video 3400 RTP/AVP 98 99 

c=IN IP6 5555: :aaa:bbb:ccc:ddd 

b=AS : 75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Route: The SIP re-INVITE request contains the saved list of Route header fields that the SCC AS has saved for 
the remote leg of the call. 

SDP: specifies the new IP address and ports used for the media components. In this case, the audio component is 
still using the original address and port while the video component is using the new IP address and new port 
allocated. 

10. SIP re-INVITE request (intermediate EM CN subsystem entities to intermediate EM CN subsystem 
entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 

11. SIP re-INVITE request (intermediate EM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards UE-2 by the intermediate IM CN 

subsystem entities. 

UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that UE-1 is ready to receive 
video media on a different contact address. Since UE-2 has resources already available, it starts to send the 
media to UE-l's contact address specified in the SDP offer inamediately. 

UE-1 starts receiving the video RTP packets over IP-CAN #2. However, UE-1 can receive some out-of-sequence 
video RTP packets over IP-CAN #1. The video RTP packets are deUvered to the codec in sequence. Once UE-1 
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determine that no video will be received over IP-CAN #1 (e.g. by examining the sequence numbers in the RTP 
headers), it can relinquish the resources that it has been using for incoming video media on IP-CAN #1. 

At the same time, UE-1 still sends both the audio and video media to UE-2 over IP-CAN #1. 

Resources used for signalling on IP-CAN #1 are not released. 

12. SIP 200 (OK) response (UE-2 to intermediate EM CN subsystem entities) - see example in table A.7.3-12 

Upon receiving the SIP re-INVITE request containing the SDP offer, since UE-2 has all resources available, it 
sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

Table A.7.3-12: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP pcscf 2 . visited2 .net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , 

SIP/2 . 0/UDP scscf2 .home2 .net;branch=z9hG4bK764z87 .1, 

SIP/2 . 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, 

SIP/2 . 0/tIDP sccas .homel .net;branch=z9hG4bK332b33 . 3 
Record-Route : <sip:pcscf 2 . visited2 .net : 5088 ; Ir ; comp=sigcomp> , <sip: scscf 2 .home2 .net ; lr>, 

<sip : scscf 1 .homel .net; lr> 
P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip:userl_publicl@homel .net>; tag=1717777 

To: <tel:+l-212-555-2222>;tag=4321 

Call-ID: dcl4bltl0b3teghmlk5013333 

CSeq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip:user2 j)ublicl@home2 .net ; gr=urn:uuid: 2ad8950e-4 8a5-4a74 -8d99- 
ad76cc7f c74> ; +g . 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel " > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933623 2987933624 IN IP6 5555 : : eee : f f f : aaa :bbb 
s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 
t=0 

m=audio 6544 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des : qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode - set=0 , 2 , 5 , 7 ; mode-change-period=2 
a = r tpmap : 9 6 t e 1 ephone - event 
a=maxpt ime : 2 

m=video 10001 RTP/AVP 98 99 
b=AS:75 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 



13. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 

15. SIP ACK request (SCC AS to intermediate EM CN subsystem entities) 
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The sec AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

16. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

17. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to UE-2. 

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
18 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header field that was received in the initial SIP INVITE request 
(step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) 
response to the initial SIP INVITE request contains the SDP answer derived from the SDP answer that the SCC 
AS has received in the SIP 200 (OK) response to SIP re-INVITE request from UE-2 (Step 14). 

Table A.7.3-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1 , 
SIP/2 . 0/UDP pcscfl .homel .net ;branch=z9hG4bK24 0f 34 . 1 , 

SIP/2 . 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:sccas. homel .net;lr>,<sip:scscfl. homel . net ; lr> , <sip : 

GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV(apcscfl. homel. net ;lr> 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 
To: <tel : +1-212 -555 -2222 >;tag=8009 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, outbound 

Contact : < sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 950e-4 8a5-4a74-8d99- 

ad7Scc7f c74 > ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: eee : fff : aaa :bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t = 

m=audio RTP/AVP 97 96 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a = r tpmap :96 telephone- event 
m=video 10001 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 



19. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 
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UE-1 receives the SIP 200 (OK) response containing the SDP answer indicating that UE-2 is ready to receive 
media. Since UE-1 has already resources available, it starts to send video media over IP-CAN #2 to UE-2's 
contact address specified in the SDP answer immediately. 

The UE-1 can relinquish the resources that it has been using for outgoing video media on IP-CAN #1. 
Resources used for signalling and audio media on IP-CAN #1 are not released. 

20. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

21. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

22. SIP re-INVITE request (UE-1 to intermediate EM CN subsystem entities) - see example in table A.7.3-22 

UE-1 updates the old call leg on IP-CAN #1 by sending a SIP re-INVITE request to the intermediate IM CN 
subsystem entities. 

Table A.7.3-22: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip :user2_publicl@home2 .net ; gr=urn : uuid : 2ad8950e-4 8a5-4a74 - 8d99-ad76cc7f c74> SIP/2 . 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : eee] : 2468 ; comp=sigcomp ;branch=z9hG4bKashdnsl 
Max-Forwards: 70 

Route : sip :XopDDDsn0oFFFXRdV9BAXpT3coNuiGKV@pcscf 1 . homel . net : 8 76 5 ; Ir ; comp=sigcomp> , 

<sip : origOscscf 1 . homel . net ; lr> 
P-Access-Network-Info : 3GPP-UTRAN-FDD; utran-cell-id-3gpp=123456ABCDE22 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=64727891 
To: <tel : +l-212-555-2222>; tag=774321 
Call -ID: me 3aOs0 9a2sdfgjkl4 91777 
Cseq: 101 INVITE 

Supported: lOOrel; precondition; tdialog 
Require: sec-agree; 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=12345678 ; portl=2468 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 
00a0c91e6bf6;ob>;+g. 3gpp . icsi - ref = "urn%3Aurn- 7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp ; application/3gpp- ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933000 2987933001 IN IP6 5555 :: aaa :bbb : ccc : eee 

s = - 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS : 25 . 4 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS. 

24. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
24 

The SCC AS updates the old call leg based on the SIP re -INVITE request and sends the SIP 200 (OK) response 
to the SIP re-INVITE request to the intermediate IM CN subsystem entities, using the content of the Via header 
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field that was received in the SIP re-INVITE request (step 23). In this example the SCC AS includes the contents 
of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) response to the SIP re- 
INVITE request contains the SDP answer derived from the SDP answer that the SCC AS previously received 
fromUE-2 (Step 14). 

Table A.7.3-24: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel .net ;branch=z9hG4bK345b32 . 2 , 
SIP/2 .0/UDP pcscf 1 .homel. net; branch=z9hG4bK568f 3 5 . 1 , 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : eee] : 2468 ; comp=sigcomp; branch=z9hG4bKashdnsl 
Record-Route : <sccas .homel .net ; lr> , <sip : scscf 1 .homel .net ; lr>, <sip: 

XopDDDsn0oFFFXRdV9BAXpT3coNuiGKV@pcscf 1 . homel . net ; lr> 
Privacy: none 

From: <sip:userl_publicl@homel .net>; tag=64727891 
To: <tel:+l-212-555-2222>;tag=774321 
Call -ID: me03a0s09a2sdfgjkl4 91777 
Cseq: 101 INVITE 

Supported: lOOrel; precondition 

Contact : < sip:user2 j>ublicl@home2 .net ; gr=urn:uuid: 2ad8950e-4 8a5-4a74 -8d99- 
ad76cc7f c74>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933800 2987933801 IN IP6 5555 :: eee : fff : aaa :bbb 
s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 
t=0 

m=audio 6544 RTP/AVP 97 96 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



25. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 

26. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the old call leg update with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

27. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 



A.8 Signalling flows for PS-PS access transfer in 
conjunction with PS-CS access transfer 

A.8.1 Introduction 

The signalling flows for PS-PS access transfer conjunction with PS-CS access transfer demonstrate how a multimedia 
session is tranferred from Source Access Leg to the Target Access Leg. The following signalling flows are included: 

- subclause A.8. 2 shows an example when a multimedia session is transferred from one IP-CAN to a new IP-CAN 
and the CS bearer respectively ; and 
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- subclause A. 8. 3 shows an example when a multimedia session is transferred from one IP-CAN and CS bearer to 
a new IP-CAN. 

A.8.2 PS - PS in conjunction with PS - CS Access Transfer: PS to 
CS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 before access transfer. 
When SC UE connects to a new IP-CAN#2, it decides to transfer the multimedia session over the new IP-CAN#2 and 
the CS bearer respectively. 
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Figure A.8.2-1 : Signalling flow for PS - PS in conjunction with PS - CS Access 

Transfer: PS to CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over 
old IP-CAN is identified with "CaU-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=774321". The UE A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE 
A initiates the handover procedure. 

Table A.8.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 

NOTE 2: To later show how the media is transferred to the new IP-CAN and CS bearer, only the SDP offer is 
shown in table A.8.2-1. 

Table A.8.2-1 : SIP INVITE request (SC UE A to intermediate IIUI CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 
Via: 

Max- Forwards : 
Route : 

P-Asserted- Identity: 

P- Charging- Vector : 

P-Access -Network- Info: 

Privacy: 

From: 

To: 

Call-ID: 

Cseq : 

Supported: 
Require : 
Proxy-Require : 
Security-Verify: 
Contact : 
Allow: 
Accept : 
Content -Type : 
Content -Length : (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 
s= 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
a=accept- types : text/plain 



2. SC UE A connects to a new IP-CAN#2: 

The SC UE A decides to transfer the multimedia session over the new IP -CAN and CS bearer respectively. The 
UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the 
new IP-CAN using multiple registrations procedure. Depending on the UE A configuration, the discovery of the 
P-CSCF in the new IP-CAN can be needed. Based on the UE A and new IP-CAN capabilities, the UE A decides 
to use the same codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new 
IP-CAN that will be needed for the signalling and transferred media, prior to sending the initial SIP INVITE 
request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A,8.2-3 
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The SC UE A sends an initial SIP INVITE request with a STI and a new SDP offer to the UE B that indicates 
that the new call replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and 
specifies in the SDP a new contact address that will be used for non-realtime media over the new IP-CAN. Upon 
sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new IP- 
CAN or the old IP-CAN. The RTP packets can arrive over the new IP-CAN prior to the SC UE are receiving the 
SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb: ccc : f f f ] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 75 31 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel .net ; lr> 
P-Pref erred-Identity: "John Doe" <sip :userl_publicl@homel . net> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel .net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID: Cb0 3a0s09a2sdfglkj4 90237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl®homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765- 

0a0c91eGbfG>;+g. 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Target -Dialog: me 3aOs0 9a2sdfgjkl4 91777; to-tag=774321 ; f rom-tag=64 72 7891 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : fff 

s= 

t = 

m=audio RTP/AVP 97 96 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
C=IN IP6 5555: :aaa:bbb:CCC:fff 
a=accept- types : text/plain 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP EWITE request (intermediate EM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities)- See example in table A.8.2-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
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request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74>; SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; Ir > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 

P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel:+l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : < sip : userl_publicl®homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : f f f 
s=t=0 

m=audio RTP/AVP 97 96 

c=IN IP6 5555: :aaa:bbb:ccc:ddd 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 20 

m=message 7654 TCP/MSRP 98 
c=IN IP6 5555: :aaa:bbb:ccc:fff 
a=accept- types : text/plain 



8. SIP re-EWITE request (Intermediate EM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The non-realtime media is using the new IP -CAN while the realtime media path is still over the old IP-CAN. 

18. CC SETUP message (SC UE A to Interworking entities) 

The SC UE sends the CC SETUP message with the STN as the called party number. 
NOTE 3: STN is a PSI DN used by the UE to request a session transfer towards the SCC AS. 
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19. SIP INVITE request (Interworking entities to Intermediate EM CN subsystem entities) -see example in 
Table A.8.2-19 

Table A.8.2-19: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.homel.net; branch=z9hG4bKnashds7 
Max - Forwards : 7 

Route : <sip : icscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel: +1-237- 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj4903 3 3 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 

Contact : <sip : mgcf 2 . home2 . net ; gr> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept: application/sdp, application/3gpp- ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 



v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

20. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

21. SIP INVITE request (Intermediate EM CN subsystem entities to SCC AS) 

22. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

23. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.8.2- 
23 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 

request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header 
field from the received SIP INVITE request. 
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Table A.8.2-23: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip : user2 publicl@home2 . net ;gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf = [5555: :b9 9:c88:d7 7:eeG] ; ccf = [5555: :a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- 

ioi= " type3homel . net " 
Privacy: none 

From: <tel : +1-23 7 - 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-2222>; tag=26545 
Call -ID: Cb0 3a0s09a2sdfglkj4 90333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 
Contact : < sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 
00a0c91e6bf G> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s= 

t = 

m=audio 3456 RTP/AVP 97 96 
c=IN IP6 5555 :: aaa: bbb: ccc : eee 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
C=IN IP6 5555: :aaa:bbb:CCC:fff 
a=accept- types : text/plain 



24. SIP re-EVVITE request (Intermediate EM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

25. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

26. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 

the SCC AS in the originating network. 

27-28. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 

to the remote UE B. 

29-30. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

31. CC CONNECT message (interworking entities to SC UE A) 
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32. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to interworking entities) 

33-34. SIP ACK request (interworking entities to SCC AS via EM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

35-36: SIP BYE request (SCC AS to SC UE A via intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP-CAN, by sending a BYE request to the 
UEA. 

37-38. SIP 200 (OK) response (SC UE A to SCC AS via intermediate EM CN subsystem entities) 

Upon receiving the BYE SIP request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A rehnquishes all resources pertaining to the old IP-CAN. 

39. Media paths between SC UE A and UE B 

Finally, the non-realtime media path is over the new IP-CAN and the realtime media is using the CS bearer. 

A.8.3 PS - PS in conjunction with PS - CS Access Transfer: CS to 
PS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 and CS bearer before 
access transfer. When SC UE connects to a new IP-CAN#2, it decides to transfer all the multimedia session over the 
new IP-CAN#2. 
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Figure A.8.3-1 : Signalling flow for PS - PS in conjunction with PS - CS Access 
Transfer: CS to PS 



NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 
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1. SC UE A has an ongoing multimedia session with remote UE B 

The non realmedia path is over old IP-CAN#1 and the realtime media path is over the CS bearer. The call has 
been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over old IP-CAN#1 
is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "Fromtag=64727891", and "To tag=774321". The UE 
A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE A initiates the 
handover procedure. 

2. SC UE A connects to a new IP-CAN#2 

The SC UE A decides to transfer the multimedia session over the new IP-CAN#2. The UE A obtains an IP 
address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using 
multiple registrations procedure. Depending on the UE A configuration, the discovery of the P-CSCF in the new 
IP-CAN can precede this. Based on the UE A and new IP-CAN capabilities, the UE A decides to use the same 
codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new IP-CAN that will 
be needed for the signalling and transferred media, prior to sending the initial SIP INVITE request. 

3. SIP EVVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.3-3 

Upon sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new 
IP-CAN or the old IP -CAN. The RTP packets can arrive over the new IP-CAN prior to the SC UE are receiving 
the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.3-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel :+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max- Forwards : 70 

Route : sip : pcscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl®homel . net > ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID : Cb03a0s09a2sdfglkj 490237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp . icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi .mmtel " 
P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 

Contact : <sip : userl_publicl@homel . net ; gr= urn : uuid : f 81d4f ae-7dec-lldO - a765 - 
00a0c91e6bf G> ; +g . 3gpp . icsi -ref = "urn%3Aurn-xxx%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 

Replaces: me03a0s0 9a2sdf gj kl491777 ; to-tag=774321 ; f rom-tag=64727891 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : fff 
s= 

c=IN IP6 5555 :: aaa :bbb : ccc : fff 

t = 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
a=accept - types : text/plain 



Request-URI: Contains the static STI. 
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4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate EM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iPC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities)- See example in table A.8.3-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip : user2_publicl®home2 . net ;gr=urn : uuid : 2ad8 950e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max- Forwards : 6 7 

Route: <scscf 1 . homel . net ; Ir > , <sip : scscf 2 . home2 . net ; lr> , <sip :pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 

P-Access -Network- Info : IEEE- 8 02 . lib 
Privacy: none 

P- Charging- Vector : icid-value = "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=559812 
To: <tel:+l-237-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50132 3 7 
Cseq: 111 INVITE 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lld0-a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Content -Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : f f f 

s= 

c=IN IP6 5555: :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVPF 97 96 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 

m=message 7654 TCP/MSRP 98 
a=accept - types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 

9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate EM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 

11-12: SIP ACK request (SCC AS to UE B via Intermediate EM CN subsystem entities) 
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The sec AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The multimedia is using the new IP-CAN. Resources used for signalling on the old IP-CAN#1 and CS bearer are 
not released. 

18-19. SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN#1, by sending a SIP BYE request 
towards the SC UE A. 

20-21. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN#1, the SC UE A sends a SIP 200 (OK) response over 
the old IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN. 

22-23. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

24-25. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A rehnquishes all resources pertaining to the CS 
bearer. 

26-27. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 
28. Media paths between UE A and UE B 

The multimedia session is using the new IP-CAN#2. 

A.9 Signalling flows for media adding/deleting for access 
transfer 

A.9.1 Introduction 

The signalhng flows for media adding/deleting demonstrate how the media of a multimedia session is added or deleted. 
The following signalling flow is included: 

- subclause A.9. 2 shows an example when the non-realtime media of a multimedia session over the IP-CAN is 
removed. 

A.9. 2 Remote End Initiation case - Removing media from split CS 
and PS sessions 

As a precondition the SC UE A has a CS call and IMS multimedia session with the remote UE after session transfer in a 
manner that more than one session are presented to UE B as one IMS session by the SCC AS. 



ETSI 



3GPP TS 24.237 version 10.2.0 Release 10 



127 



ETSI TS 124 237 VI 0.2.0 (2011-04) 



SCUE A 


IP 


CS 



Interworking 
entities 



Intermediate IM 
CN subsystem 
entities 



sec AS 



UEB 



SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 



■la.CSbearep-- 



■la.realtime media path- 



■Ib.non-realtime media path- 



-9. SIP BYE- 



-10. SIP 200 (OK)- 



•12.CS bearer- 



-2. SIP relNVITE 



-3. SIP relNVITE* 
4. SIP 200 (OK) 



relNVITE 
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-6. SIP ACK- 



-7 SIP ACK- 
-8. SIP BYE- 



-11. SIP 200 (OKy 
■12.realtime media path — 



Figure A.9.2-1 : Remote End Initiation case - Removing media from split CS and PS 

sessions 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 
1. SC UE A has an ongoing multimedia session witli remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

Table A.9.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 
NOTE 2: To show how the media is removed, only the SDP offer is shown in this example. 
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Table A.9.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 
Via : 

Max- Forwards : 
Route : 

P- Asserted- Identity: 

P- Charging- Vector ; 

P- Access -Network- Info: 

Privacy : 

From : 

To : 

Call-ID: 
Cseq : 

Supported : 
Require : 
Proxy-Require : 
Security-Verify : 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : CCC : ddd 
s = 

c=IN IP6 5555 :: aaa : bbb : CCC : ddd 
t = 

m=message 7654 TCP/MSRP 98 
a=accept- types : text/plain 



2. SIP re-EWITE request (UE B to intermediate EM CN subsystem entities)- See example in table A.9.2.-2 

The remote UE B decides to remove the non-realtime media from the multimedia session. It uses standard IMS 
procedures to remove one or more PS media from the session. 
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Table A.9.2-2: SIP re-INVITE request (UE B to intermediate IM CN subsystem entities) 



INVITE < sip : userlpubliclohomel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKjias34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-2222> 

P- Charging- Function- Addresses : ccf = [5555: :b9 9:c88:d7 7:eeG] ; ccf = [5555: :a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- 

ioi= " type3homel . net " 
P-Access-Network-Info : 
Privacy: none 

From: <tel: +1-23 7-555-2222; gr=hdg7777ad7af IzigSsf 7> ; tag=171828 

To: <tel : +l-237-555-llll> 

Call -ID : Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 
Contact : < sip : user2_publicl®home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 

ad7 6cc7f c74 > ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp , application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

0=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : CCC : ddd 
s= 

c=IN IP6 5555 : :aaa:bbb:ccc:ddd 

t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 20 
m=message TCP/MSRP 98 
a=accept- types : text/plain 



3. SIP re-EWITE request (Intermediate IM CN subsystem entities to SCC AS) 

4-5. SIP 200 (OK) response (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the remote 
UEB. 

6-7: SIP ACK request (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP ACK request to the SIP SIP 200 (OK) response and forwards it to the SCC AS. 

8-9: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the IP-CAN, by sending a SIP BYE request to the 
UEA. 

10-11. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the IP-CAN, the SC UE A sends a SIP 200 (OK) response over the IP- 
CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the IP-CAN. 

12. Media paths between SC UE A and UE B 

Finally, the non-realtime media path over the IP-CAN is removed. 



ETSI 



3GPP TS 24.237 version 10.2.0 Release 10 



130 



ETSI TS 124 237 VI 0.2.0 (2011-04) 



A.10 Void 

A. 11 Void 

A. 12 Void 

A.I 3 Void 

A.I 4 Void 

A.I 5 Signalling flows for MSG server assisted mid-call 
feature 

A.15.1 Introduction 

The signalling flows in the subclause demonstrate how full duplex session on hold can be transferred together with 
active full duplex session when the MSC server assisted mid-call feature is used. The following signalling flows are 
included: 

- subclause A.15.2 shows an example of CS to PS access transfer with the MSC server assisted mid-call feature. 

- subclause A.15.3 shows an example of PS to CS access transfer with the MSC server assisted mid-call feature. 

subclause A.15.4 shows an example of PS to CS access transfer with MSC server assisted mid-caU feature with 
an incoming waiting call in alerting phase 

The examples assume that: 

- the SC UE, the MSC server enhanced for ICS and the SCC AS support the MSC server assisted mid-call feature; 

- the SC UE does not use ICS procedures; and 

- the SCC AS is allowed to use the MSC server assisted mid-call feature according to operator policy. 

A.15.2 CS to PS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A. 15. 2-1, SC UE A has two ongoing sessions over CS bearer which are anchored at 
SCC AS. The active session X is with UE B, the held session Y is with UE C. The session X and session Y are two 
party sessions. The session Y contains rejected video stream and accepted audio stream. When the SC UE connects to 
an IP-CAN, it decides to transfer the sessions over the IP-CAN. 
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1. SC UE A is on an active session X with UE B and held session Y with UE C. Both calls are anchored at 

sec AS. 



■la.CS bearer-' 



2. UE A connects to a new IP-CAN and decides to 
transfer the session over the new IP-CAN. It 
reserves resources in the new IP-CAN. 
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Figure A.1 5.2-1 : Signalling flow for PS-CS Access Transfer: CS to PS 
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NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SC UE A has an ongoing active session X with remote UE B and a held session Y with remote UE C 
The calls have been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the sessions over the new IP-CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request transferring the active session X (SC UE A to intermediate IM CN subsystem 
entities) - see example in table A.15.2-3 

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing call X. 
Table A.15.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain .xferOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKiiashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . homel .net:7531;lr>, <sip: origOscscf 1 . homel . net ; lr> 
P- Preferred- Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl®homel . net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID : Cb03a0s0 9a2sdfglkj4 9023 7 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu, norefersub 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lld0-a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " ; +g . 3gpp .mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml , application/vnd. Sgpp .mid-call+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s= 

C=IN IP6 5555 :: aaa : bbb : ccc : ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a= r tpmap : 9 6 t e 1 ephone - event 
a=maxpt ime : 2 



Contact: contains the g.3gpp.mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-call feature MIME type. 

4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 
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The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-EVVITE request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP re-lNVlTE request 
contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE 
request from the UE A (Step 3). 

8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-lNVlTE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate EM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate EM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The media path of session X is using the new IP-CAN but the media path of the session Y is stiU using the CS 
bearer. 

18-19. SIP BYE request (SCC AS to MSC Server via intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

20-22. CC DISCONNECT message (interworldng entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A rehnquishes all resources pertaining to the CS 
bearer. 

23-24. SIP 200 (OK) response (MSC Server to SCC AS via intermediate EM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the MSC Server sends a SIP 200 (OK) response over 
the old IP-CAN to the SCC AS. 

25: SIP REFER request (SCC AS to Intermediate EM CN subsystem entities) -see example in table A.15.2-25 

The SCC AS sends SIP REFER request towards UE A inside the dialog created by the message 13. 
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Table A.1 5.2-25: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: SIP/2. 0/UDP sip:sccasl.homel.net;branch=z9hG4bk731b8a 
Max-Forwards: 70 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 

From: <tel : +l-237-555-2222>; tag=aasdf gaag 

To: <sip : userl_publicl®homel . net> ; tag=171828 

Call -ID: Cb0 3a0s09a2sdfglkj4 90237 

Cseq: 55998 REFER 

Content-Length: . . . 

Route : <sip : scscf 1 . homel . net ; lr> , <sip :pcscf 1 . homel . net : 7531 ; lr> 
Contact : <sip : sccasl . homel .net ; gr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Refer- To : <sip : additional . session . xf erOsccas . homel . net ?Target-Dialog=a84b4c76e66710%3Bremote- 
tag=e543G4735%3Blocal-tag=192B301774&Require=tdialog&From=tel : +l-237-555-llll&To=tel : +1- 
9B7-654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 
%2 02 987933 623 %2 02 987933 623 %2 0IN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0As%3D- 
%0D%0Ac%3DIN%20IP6%205555 : :ggg: f f f :aaa:bbb%0D%0At%3D0%2 0%0D%0Am%3Dvideo%2 00%2 0RTP%2FAVP%2 
98%0D%0Am%3Daudio%2 03456%2 0RTP%2FAVP%2 097%2 096%0D%0Ab%3DAS : 25 . 4%0D%0Aa%3Drtpmap : 97%20AMR%0D 
%0Aa%3Dfmtp: 97%2 0mode-set%3D0%2C2%2C5%2C7%3B%2 0mode-change- 
period%3D2%0D%0Aa%3Dmaxptime : 20%0D%0A> 

Content -Type : application/vnd . 3gpp . mid-call+xml 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 
<mid-call/ > 



Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields: 
Target-Dialog: the dialog identifier of the source access leg. 
Require: containing "tdialog" option tag 
From: contains the public user identity of the UE A 
To: contains the public user identity of the UE C 

Content-Type: containing "apphcation/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 

26. SIP REFER request (intermediate IM CN subsystem entities to UE A) 

The SIP REFER request is forwarded towards the UE A. 

27-28. SIP 202 (Accepted) response (UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the UE A sends a SIP 202 (Accepted) response. 

29. SIP INVITE request transferring the held session Y (SC UE A to intermediate IM CN subsystem entities) 
- see example in table A.15.2-29 

The SC UE A sends an initial SIP INVITE request to request the new call replacing the existing call Y. 
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Table A.1 5.2-29: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : additional . session . xferOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKjiashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . homel . net :7531;lr>, <sip: origOscscf 1 . homel . net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <tel : +l-237-555-llll>; tag=171828 
To: <tel : +l-987-654-3210> 
Call-ID: asdfqweasas 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " ; +g . 3gpp .mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; application/3gpp-ims+xml 

Target -Dialog: a84b4c76e66710 ; remote-tag=654364 735 ; local -tag=192 83 01774 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s= 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=video RTP/AVP 98 

m=audio 3456 RTP/AVP 97 96 

b=AS : 25 . 4 

a=curr:qos loca 

a=tcap:l RTP/AVPF 

a=pcfg:l t=ll sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 
a=sendonly 



Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the 
SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 
MSG server assisted mid-caU feature. 

SDP: All the media are offered with the sendonly directionality. 

30. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

31. SIP EWITE request (intermediate EM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

32. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

33. SIP re-INVITE request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP re-INVITE request 
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contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE 

request from the UE A. 

34. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 
35-36: SIP 200 (OK) response (UE C to SCC AS via Intermediate EM CN subsystem entities) 

The UE C generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
37-38: SIP ACK request (SCC AS to UE C via Intermediate EM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE C. 
39: SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
40: SIP 200 (OK) response (Intermediate EM CN subsystem entities to UE A) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
41-42: SIP ACK request (SC UE A to SCC AS via Intermediate EM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
43. Media paths between UE A and UE B 

The media paths of session X and session Y are using the new IP -CAN but the the CS bearer is still not released. 
44-45. SIP BYE request (SCC AS to MSC Server via intermediate EM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

46-48. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A reUnquishes all resources pertaining to the CS 
bearer. 

49-50. SIP 200 (OK) response (MSC Server to SCC AS via intermediate EM CN subsystem entities) 
51. Media patlis between UE A and UE B 

The media paths of session X and session Y are using the new IP-CAN. 

A. 15.3 PS to CS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A.15.3-1, SC UE A has two ongoing sessions over PS bearer which are anchored at 
SCC AS. When both sessions were established the SC UE and the SCC AS included the g.3gpp.mid-call media feature 
tag as specified in annex C into the Contact header fields. The active session X is with UE B, the held session Y is with 
UE C. The session X and session Y are two party sessions. The session Y contains a rejected video stream and an 
accepted audio stream. When the SC UE attaches to the CS domain, it decides to transfer the sessions over the CS 
bearer without using the ICS capability. 
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Figure A.1 5.3-1 : Signaiiing fiow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SC UE A is on an active session X with UE B and a held session Y with UE C: 

There is an ongoing IP bearer between the SC UE and the remote UE B and another IP bearer between the SC 
UE and the remote UE C. Both sessions are anchored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the sessions over the CS bearer. 

3. CC SETUP messages 
Transaction Identifier: 3 
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4. SIP INVITE request transferring the active session X (MSC Server to Intermediate IM CN subsystem 
entities) -see example in table A. 15.3-4 

Upon receiving the CC SETUP message the MSC Server sends a SIP INVITE request and associates the 
transaction identifier 3 with the SIP INVITE request. 

Table A.I 5.3-4: SIP INVITE request (MSC Server to Intermediate IM CN subsystem entitles) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . homel .net ;branch=z9hG4bk731b87 
Max- Forwards : 70 

P-Asserted- Identity: <tel : +l-237-555-llll> 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 
Privacy: none 

From: <tel : +1-23 7-555 -1111> ; tag=17182 8 
To: <tel:+l-237-555-3333> 
Call-ID: Cb03a0s09a2sdfglkj490333 
Cseq: 12 7 INVITE 

Supported: lOOrel, precondition, gruu, 199, norefersub 

Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
P-Asserted-Service : urn:urn-7 : 3gpp-service . ims . icsi .mmtel 

Contact : <sip:userl j)ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6> ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp . ics=" server" ; +g. 3gpp .mid- call 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content -Length: (...) 

Accept: application/sdp; application/3gpp-ims+xml , application/vnd. 3gpp .mid-call+xml 
Recv-Info: g . 3gpp .mid-call 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 
t=0 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des : qos none remote sendrecv 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



Request-URI: contains the IMRN, as obtained fi-om CS networks signalhng. 
SDP: The SDP contains preconfigured set of codecs supported by the MSC Server. 

Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 

MSC server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-call feature MIME type. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 

towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

8. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities) 
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The sec AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP 
INVITE request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 

9. SIP re-INVITE request (Intermediate EM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has aU resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to MSC Server via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

16. CC CONNECT message (MSC Server to SC UE A) 

17. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to MSC Server) 

18-19. SIP ACK request (MSC Server to SCC AS via IM CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 
20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearers are still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session X, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes aU resources pertaining to the old IP-CAN. 

25. Media paths between SC UE A and UE B 

The session X is transferred from PS bearer to CS bearer, but the session Y is stiU at the PS bearer. 

26. SIP REFER request (SCC AS to IM CN subsystem entities) -see example in table A.15.3-26 

The SCC AS sends SIP REFER request towards MSC Server inside the dialog created by the the message 14. 
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Table A.1 5.3-26: SIP REFER request (SCO AS to IM CN subsystem entities) 



REFER sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: SIP/2. 0/UDP sip:sccasl.homel.net;branch=z9hG4bk731b8a 
Max-Forwards: 70 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 

To : <tel : +1-237- 555- llll>;tag=171828 

From: <tel : +1-237- 555-3333 >; tag=sdfsdf 

Call -ID: Cb0 3a0s09a2sdfglkj4 90333 

Cseq: 55998 REFER 

Content-Length: 125 

Route : <sip : scscf 1 . homel . net ; lr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Contact: sip : sccasl . homel . net 

Refer- To : < additional . session . xf erOsccas . homel . net ?Target-Dialog=ksdj f hwrklf %3Bremote- 
tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel : +l-237-555-llll&To=tel : +l-987- 
654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 
%202987933G23%202987933G23%20IN%20IP6%205555 : :ggg: f f f :aaa:bbb%0D%0As%3D- 
%0D%0Ac%3DIN%20IPG%205555 : :ggg: f f f :aaa:bbb%0D%0At%3D0%2 0%0D%0Am%3Dvideo%2 00%2 0RTP%2FAVP%2 
98%0D%0Am%3Daudio%2 0345G%2 0RTP%2FAVP%2 097%2 096%0D%0Ab%3DAS : 25 . 4%0D%0Aa%3Drtpmap : 97%20AMR%0D 
%0Aa%3Dfmtp: 97%2 0mode-set%3D0%2C2%2C5%2C7%3B%2 0mode-change- 
period%3D2%0D%0Aa%3Dmaxptime : 20%0D%0A> 

Content -Type : application/vnd . 3gpp . mid-call+xml 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 
<mid-call/ > 



Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields: 
Target-Dialog: the dialog identifier of the source access leg. 
Require: containing "tdialog" option tag 
From: contains the public user identity of the UE A 
To: contains the public user identity of the UE C 

Content-Type: containing "apphcation/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 

27. SIP REFER request (intermediate EM CN subsystem entities to MSC Server) 

The SIP REFER request is forwarded towards the MSC Server. 

28-29. SIP 202 (Accepted) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the MSC Server sends a SIP 202 (Accepted) response. 

30. SIP INVITE request for the held session Y (MSC Server to Intermediate IM CN subsystem entities) -see 
example in table A.15.3-30 

Upon receiving the SIP REFER request the MSC Server sends a SIP INVITE request and associates the 
transaction identifier 4 with the SIP INVITE request. 
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Table A.1 5.3-30: SIP INVITE request (MSG Server to intermediate IM CN subsystem entities) 



INVITE 

sip : additional . session . xf erOsccas . homel . net SIP/2.0 
Via: SIP/2. 0/UDP mscl. homel. net;branch=z9hG4bk731b87 

Max-Forwards: 70 

P-Asserted- Identity : <tel:+l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel : +1-237- 555- 1111> ; tag=171828 
To: <tel : +l-987-654-3210> 
Call-ID: asdfgqwerq 
Cseq: 1275 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= " server" ; +g . 3gpp . mid- call 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Target-Dialog : ksdj f hwrklf ; remote-tag=676723565 ; local-tag=45418454 
Require : tdialog 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s= 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 

t = 

m=video RTP/AVP 98 
m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 
a=sendonly 



Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the 
SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 
MSG server assisted mid-caU feature. 

SDP: The SDP contains preconfigured set of codecs supported by the MSG Server. All the media are offered 
with the sendonly directionaUty. 

31. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SG user and as a result routes the SIP INVITE request 
towards the SGG AS. 

32. SIP EWITE request (Intermediate EM CN subsystem entities to SCC AS) 

33. Remote Leg Update 

The SGG AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

34. SIP re-EWITE request (SCC AS to intermediate EM CN subsystem entities) 

The SGG AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE G via the 
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intermediate IM CN subsystem entities. The SIP re-INVITE request contains the SDP offer that is identical to 
the SDP offer that the SCC AS received in the initial SIP INVITE request from the UE A. 

35. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C) 
Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 

36. SIP 200 (OK) response (UE C to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE C has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

37. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

38-39. SIP ACK request (SCC AS to UE C via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE C. 

40. SIP 200 (OK) response (SCC AS to IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

41. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC Server) 

Intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP INVITE request to MSC 
Server. 

42-43. SIP ACK request (MSC Server to SCC AS via IM CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 

44. Media paths between SC UE A and UE B: 

The CS bearer and PS bearers for both the sessions are established but there is still the original IP bearer for the 
held session Y. 

45-46: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session Y, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

47-48. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

49. Media paths between SC UE A and UE B 

Both sessions X and Y are transferred from PS bearer to CS bearer. 

A. 15.4 PS to CS access transfer with MSC server assisted mid-call 

feature with an incoming waiting call in alerting phase 

In the example flow at the figure A. 15. 4-1, SC UE A has an ongoing sessions and an incoming waiting call over PS 
bearer which are anchored at SCC AS. The incoming waiting call is in alerting state. The ongoing session X is with UE 

B, the incoming waiting session Y is with UE C. The session X and session Y are two party sessions. Based upon 
measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to trigger a SRVCC procedure to 
CS access. 
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Figure A.1 5.4-1 : Signalling flow for PS to CS access transfer with IVISC server assisted mid-call 
feature with an incoming waiting call in alerting phase 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. SC UE A is on an active session X with HE B and an incoming waiting session Y with UE C: 

There is an ongoing PS bearer between the SC UE and the remote UE B and another PS bearer between the SC 
UE and the remote UE C. Both sessions are anchored at SCC AS. 

2. SC UE A sends the measurement reports to E-UTRAN 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPPTS 23.237 [9]. 

3-24. Access transfer for the active session X 

The procedure for transfering the active session X is the same as described in subclause A. 15.3. 

25. Media paths between SC UE A and UE B 

The session X is transferred from PS bearer to CS bearer, but the session Y is still at the PS bearer. 

26. SIP REFER request (SCC AS to EM CN subsystem entities) -see example in table A.15.4-26 

The SCC AS sends SIP REFER request towards MSC server inside the dialog created by the the message 14, 
and it also contain the state-and-event-info XML body to indicate that the additional session is an incoming 
session in alerting phase. 

Table A.15.4-26: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip:userl j>ublicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2 . 
Via: SIP/2. 0/UDP sip : sccasl . homel .net ;branch=z9hG4bk731b8a 
Max- Forwards : 70 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 

To: <tel:+l-237-555-llll>;tag=17182 8 

From: <tel : +l-237-555-3333> ; tag=sdf sdf 

Call-ID: Cb03a0s09a2sdfglkj490333 

Cseq: 55998 REFER 

Content -Length: 125 

Route : <sip: scscf 1 .homel .net ; lr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Contact: sip : sccasl . homel .net 

Refer-To : <additional . session . xf er@sccas . homel . net?Target-Dialog=ksdj f hwrklf %3Bremote- 
tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel : +l-237-555-llll&To=tel : +1-987 - 
654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 
%202987933623%202987933623%20IN%20IP6%205555 : : ggg : f f f : aaa : bbb%0D%0As%3D- 

%0D%0Ac%3DIN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0At%3D0%2 00%0D%0Aaudio%2 03456%2 0RTP%2FAVP%2 09 
7%2096%0D%0Ab%3DAS:25 .4%0D%0Aa%3Drtpmap: 97%20AMR%0D%0Aa%3Dfmtp: 97%20mode- 
set%3D0%2C2%2C5%2C7%3B%2 0mode-change-period%3D2%0D%0Aa%3Dmaxptime:2 0%0D%0A> 
Content -Type : boundary=boundaryl 

- -boundaryl 

Content-Type : application/vnd . 3gpp.mid-call+xml 
<?xml version="l . 0" encoding="UTF-8"?> 
<mid-call/> 

- -boundaryl 

Content -Type : application/vnd. 3gpp . state -and-event-info+xml 

<?xml version="l . 0" encoding="UTF-8"?> 
<state-and-event-inf o> 

<state-inf o>early</ state -info> 

<direction>receiver< /direct ion> 
</state-and-event-inf o> 

- -boundary- - 



Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields: 
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Target-Dialog: the dialog identifier of the source access leg. 



Require: 



containing "tdialog" option tag 



From: 



contains the public user identity of the UE A 



To: 



contains the public user identity of the UE C 



Content-Type: containing "appUcation/sdp" MIME type of the "body" URI header field 
body: SDP describing the media used in the session. 

XML Schema: contain the session state information that the additional session is an incoming session in 
alerting state. 

27. SIP REFER request (intermediate IM CN subsystem entities to MSC server) 

The SIP REFER request is forwarded towards the MSC server. 
28-29. SIP 202 (Accepted) response (MSC server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the MSC server sends a SIP 202 (Accepted) response. 

30. SIP INVITE request for the held session Y (MSC server to Intermediate IM CN subsystem entities) -see 
example in table A.15.4-30 

Upon receiving the SIP REFER request which contain the session state information to indicate that the additional 
session in an incoming session in alerting state, the MSC server moves to Call Received state as described in the 
SIP REFER request but does not generate an in-band ring tone to the calling party, and sends a SIP INVITE 
request and associates the transaction identifier with the SIP INVITE request. 
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Table A.1 5.4-30: SIP INVITE request (MSG server to intermediate IM CN subsystem entities) 



INVITE 

sip : additional . session . xf erOsccas . homel . net SIP/2.0 
Via: SIP/2. 0/UDP mscl. homel. net;branch=z9hG4bk731b87 

Max-Forwards: 70 

P-Asserted- Identity : <tel:+l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel : +1-237- 555- 1111> ; tag=171828 
To: <tel : +l-987-654-3210> 
Call-ID: asdfgqwerq 
Cseq: 1275 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 
Contact : <sip : msciohomel . net > ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 
service . ims . icsi . mmtel " ; +g . 3gpp . ics= " server" ; +g . 3gpp . mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 

Target-Dialog : ksdj f hwrklf ; remote-tag=676723565 ; local-tag=45418454 
Require: tdialog 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : CCC : eee 
S = 

c=IN IP6 5555 :: aaa : bbb : CCC : eee 

t = 

m=audio 3456 RTP/AVP 97 96 
a = tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 



Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the 

SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 

MSG server assisted mid-call feature. 

SDP: The SDP contains preconfigured set of codecs supported by the MSG server. 

31. Evaluation of initial filter criteria 

The S-GSGF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 

towards the SGG AS. 

32. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

33. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

34. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities) 

The see AS acting as a routing B2BUA generates a SIP UPDATE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE G via the 
intermediate IM GN subsystem entities. The SIP UPDATE request contains the SDP offer that is identical to the 
SDP offer that the SCC AS received in the initial SIP INVITE request from the UE A. 

35. SIP UPDATE request (Intermediate IM CN subsystem entities to UE C) 
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Intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE C. 

36. SIP 200 (OK) response (UE C to intermediate EM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer, since the UE C has all resources available, it 
sends immediately the SIP 200 (OK) response to the SIP UPDATE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

37. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP UPDATE request to 
the SCC AS in the originaling network. 

38-39. SIP 183 (Session Progress) response (SCC AS to MSC server via IM CN subsystem entities) 

The SCC AS sends a 183 (Session Progress) containing the SDP answer as received from the UE C. The SDP 
answer indicates that resources are available 

40. SIP PRACK request (MSC Server to Intermediate IM CN subsystem entities) 

The MSC server acknowledges the receipt of the 183 Session Progress. 

41. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem forward the SIP PRACK request to the SCC AS 
42-43. SIP 200 (OK) response (SCC AS to MSC server via IM CN subsystem entities) 
The SCC AS acknowledges the PRACK with a SIP 200 (OK) response to the MSC server. 

44. CS HOLD Message (SC UE to MSC server) 
The SC UE A put the active session on hold. 

45. SIP re-INVITE request (MSC server to intermediate IM CN subsystem entities) 

Upon receiving the CS HOLD Message from the UE, MSC server sends a SIP re-INVITE request towords 
session X, which put session X on hold.The SDP in this SIP re-INVITE request is based on the last SDP 
offer/answer negotiation for the active session transfer form step 3 to 24, but for each media streams set the 
SDP attribute to "sendonly". 

46. SIP re-INVITE request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP re-INVITE request is forwarded to the SCC AS. 

47-48. SIP re-INVITE request (SCC AS to UE B) 

SCC AS sends SIP re-INVITE request to UE B, The SIP re-INVITE request contains the SDP offer that is 
identical to the SDP offer that the SCC AS received in the SIP re-INVITE request from the MSC server. 

49-50. SIP 200 (OK) response (UE B to SCC AS) 

Upon receiving the SIP re-INVITE request containing the SDP offer which contain the SDP attribute for each 
media streams to "sendonly", UE B response the SIP re-INVITE request with a SIP 200 (OK), which set the SDP 
attribute for each media streams to "receonly". 

51-52. SIP ACK request (SCC AS to UE B) 

53-54. SIP 200 (OK) response (SCC AS to MSC server via intermediate IM CN subsystem entities ) 

The SCC AS sends 200 (OK) to indicate the succesfull activity to the MSC server that put session X on hold. 
55. CS HOLD ACKNOWLEDGE Message (MSC server to SC UE A) 

56-57. SIP ACK request (MSC server to SCC AS via intermediate IM CN subsystem entities) 

MSC server acknowledges the 200 OK received from SCC AS. 
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58. CS Connect Message from SC UE A to MSC server 

The SC UE A accepts the call and sends CS Connect Message. 

59. SIP EVFO request (MSC server to intermediate IM CN subsystem entities) - see example in table A.15.4- 
59 

A.1 5.4-59: INFO (SCC AS to intermediate IIUl CN subsystem entities) 



INFO sip : sccasl .homel . net ;gr SIP/2.0 

Via: SIP/2. 0/UDP mscl .visitl .net;branch=z9hG4bk731b87 
Max- Forwards : 68 

Route : <sip: scscf 1 .homel .net ; lr> 
From: <tel : +1-23 7-555 -1111> ; tag=17182 8 
To: <tel: +l-237-555-3333> ; tag=171828 
Call-ID: Cb03a0s09a2sdfglkj490334 
Cseq: 130 INFO 

Info-Package : g . 3gpp . srvcc-alerting 

Content -Type : application/vnd. 3gpp . state -and-event-info+xml 
Content -Length : 

<?xml version="l . 0" encoding="UTF-8"?> 
<state-and-event-inf o> 

<event >cal 1 -accepted< / event > 
</state-and-event-inf o> 



XML Schema: contain the session state information indicating that the remote party has answered the call. 



60. SIP INFO request (Intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the SCC AS. The SCC AS gets 
informed that the SC UE A has accepted the call. 

61. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acknowledges the receipt of the SIP INFO request indicating that the SC UE A has accepted the 
call 

62. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server) 

The SIP 200 (OK)response is forwarded to the MSC server. 

63. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends SIP 200 (OK) response to indicate to the far end that the SC UE A has accepted the call. 

64. SIP 200 (OK) response (Intermediate IM CN subsystem entities to far end) 
The SIP 200 (OK) response is forwarded to the far end) 

65. SIP ACK request (far end to intermediate IM CN subsystem entities) 

The far end UE acknowledges the SIP 200 (OK) response received from the SCC AS 

66. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is forwarded to the SCC AS. 

67. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends 200 (OK) response to indicate the succesfull access transfer to the MSC server. 

68. SIP 200 (OK) response (Intermdeiat IM CN subsystem entities to far end) 
The SIP 200 (OK) response is forwarded to the MSC server. 
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69. CS Connect Ack (MSC server to SC UE A) 

70. SIP ACK request (MSC server to intermediate EM CN subsystem entities) 

MSC server acknowledges the SIP 200 (OK) response received from SCC AS. 

71. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is forwarded to the SCC AS. 

72-73: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session Y, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

74-75. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A reUnquishes all resources pertaining to the old IP-CAN. 

76. Media patlis between SC UE A and UE B 

Both sessions X and Y are transferred from PS bearer to CS bearer. 

A.1 6 Signalling flows for SRVCC session transfer for IMS 
emergency session 

A.1 6.1 Introduction 

The signalling flows for SRVCC session transfer for IMS emergency session demonstrate how an IMS emergency 
session is transferred from PS network to CS network using SRVCC procedure. The following signalhng flow is 
included: 

subclause A. 16.2 shows an example when a UE initiating an emergency session in IMS for the case that the UE 
is not in limited service mode ;and 

- subclause A. 16.3 shows an example when the emergency session need to transfer from PS to CS using SRVCC 
procedure for the case that the UE is not in limited service mode. 

A.1 6.2 UE initiating an emergency session in IIVIS 

The signalling flows shown in figure A. 16.2-1 describes the UE initiating an IMS emergency session procedure for the 
case that the UE is not in hmited service mode. The flow illustrates the anchoring of the session at the EATF. 
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Figure A.1 6.2-1 : Signalling flow for UE initiating an emergency session in IMS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
NOTE 2: For clarity, the SIP 180 (Ringing) response is not shown in the signalling flow. 
NOTE 3: For clarity, the precondition mechanism is not shown in the signalling flow. 
1. SIP EWITE request (UE A to P-CSCF) see example in table A.16.2-2 
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INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKjiashds7 
Max-Forwards: 70 

Route : <sip:pcscf.visitl. net : 7531 ; Ir ; comp=sigcomp> 
P- Preferred- Identity : <sip : userl_publicl@homel . net > 

P-Access-Network-Info : 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From : <sip : userl_publicl®homel . net > ; tag=17182 8 

To: <urn : service : SOS . fire> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Accept : application/ sdp, application/ 3gpp-ims+xml 

Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac- sha- 1- 96 ; spi=87654321 ; port=7531 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO-aVeS- 
OOaOcgieebf 6> ; +sip . instance="<urn:gsma: imei :9 04 20156-025763-0>" 

Geolocation : <sips : 3sdef rhy2 j j 7®lis . atlanta . example . com> ; inserted- 
by= " sip : userl_publicl(ahomel . net " ; routing-allowed= "yes " 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content -Length: (...) 

v=0 

0=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : CCC : ddd 
S = 

c= IN IP6 5555 : :aaa:bbb:ccc:ddd 

t = 

m=audio 3400 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des: qos mandatory local sendrcv 

a=des : qos mandatory remote sendrcv 

a= inactive 



Contact: contains the "sip. instance" media feature tag as specified in IETF RFC 5626 [22] with a value formed 
from an IMEI as defined in 3GPP TS 23.003 [12]. 

2. SIP INVITE request (EATF to E-CSCF) see example in table A.16.2-3 
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INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP pcscf .visitl.net;branch=z9hG4bK240f34.1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 6 9 

Route : <sip:ecscf.visitl. net ; Ir ; > 

Record- Route : <sip : pcscf . visit 1 . net ; lr> 

P- Preferred- Identity : 

P -Access -Network- Info : 

Privacy: 

From : 

To : 

Call-ID: 
Cseq : 

Supported : 
Accept : 
Require : 
Proxy-Require : 
Accept-Contact : 
P-Pref erred-Service : 
Security-Verif y : 
Contact : 
Geolocation : 
Allow : 

Content-Type : 
Content -Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 

a=curr : 
a=curr : 
a=des : 
a=des : 
a= 



3. SIP EVVITE request (E-CSCF to EATF) see example in table A.16.2-4 
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INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas .visitl .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
pcscf . visitl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

Max- Forwards : 68 

Route : <sip:esccas. visitl. net ; Ir ; > 

Record- Route : <sip:ecscf. visitl .net ; lr> , <sip : pcscf .visitl .net ; lr> 

P -Preferred- Identity : 

P -Access -Network- Info: 

Privacy: 

From : 

To : 

Call-ID: 
Cseq : 

Supported : 
Accept : 
Require : 
Proxy-Require : 
Accept-Contact : 
P- Preferred- Service : 
Security-Verif y : 
Contact : 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; insert ed- 

by= " sip : userl_publicl@homel . net " ; routing-allowed= "yes " ; used- for -routing 
Allow: 

Content-Type : 
Content -Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 
a= 
a= 
a= 



4. EATF anchors the emergency session 

The EATF (acting as a routing B2BUA) anchors the emergency session, i.e. the EATF is inserted in the 
signalling path which invokes a 3pcc for enablement of Access Transfers 

5. SIP INVITE request (EATF to E-CSCF) see example in table A.16.2-5 

The EATF acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 
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INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas .visitl .net;branch=z9hG4bKnas34r5 
Max- Forwards : 67 

Route : <sip:ecscf. visitl. net : 7531 ; Ir ; comp=sigcomp> 

Record- Route : <sip:ecscf. visitl. net ; lr> 

P- Preferred- Identity: <sip :userl_publicl@homel . net > 

P- Access -Network- Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : <sip : userl_publicl@homel .net> ; tag=17182 8 

To: <urn : service : SOS . fire > 

Call -ID: Cb0 3a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Accept : application/sdp , application/3gpp- ims+xml 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec -Ild0-a765- 

OOaOcSleSbf G>; +sip. instance= " <urn : gsma : imei :9 04 2015G-0257G3-0>" 
Geolocation : <sips : 3sdef rhy2 j j 7@lis . at 1 ant a . example . com> ; insert ed-by= " 

sip : userl_publicl(ahomel . net "Crout ing-allowed= "yes " ; used- for -routing 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s= 

c= IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des: qos mandatory local sendrcv 

a=des: qos mandatory remote sendrcv 

a=inactive 



6. SIP INVITE request (E-CSCF to PSAP) 
E-CSCF routes the SIP INVITE request to the PS/VP. 

7. SIP 200 (OK) response (PSAP to E-CSCF) see example in table A.16.2-6 

Table A.16.2-6: SIP 200 OK 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ecscf . visitl . net ,-branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Record- Route : <sip: ecscf. visitl. net ; lr> , <sip : pcscf .visitl . net ; lr> 
Privacy: none 

From : <sip :userl_publicl®homel . net > ; tag=17182 8 
To: < urn : service ; SOS . fire > ; tag=232456 
Call-ID: 
Cseq: 

Require: lOOrel, precondition, 199, gruu 
Contact: <sip : mgcf . visitl . net > . 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content -Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s= 

c= IN IP6 5555: :fff:eee : ccc :ddd 
t=0 

m=audio 3400 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des : qos mandatory remote sendrcv 

a= inactive 
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8-9. SIP 200 (OK) response (E-CSCF to EATF and to E-CSCF) 

E-CSCF forwards the SIP 200 (OK) response. 
10-11. SIP 200 (OK) response (E-CSCF to UE A) see example in table A.16.2-7 

Table A.16.2-7: SIP 200 (OK) response 



SIP/2.0 200 OK 
Via : 

Max-Forwards: 65 
Record-Route : 
Privacy: 
From : 
To : 

P- Asserted- Identity: tel : 911 ; context="+l" 

Call-ID: 
Cseq : 
Require : 
Contact : 
Allow: 

Content-Type : 
Cent ent - Length : 

v= 
o= 
s= 
c= 
t= 
m= 
a= 
a= 
a= 
a= 
a= 



12. SIP ACK request 

UE A responds to the 200 (OK) response with a SIP ACK request. 

A.1 6.3 Session transfer for emergency session using SRVCC 
procedure: PS-CS 

In the example in figure A. 16.3-1, UE A (which has a valid subscription, is authenticated and authorized for PS service 
and is normal attached to the network) has an ongoing emergency session with a PSAP using a PS bearer which is 
anchored at EATF. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to 
trigger a SRVCC handover to CS access. 
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UE A 



Interworking 
Entities 



P-CSCF 



I-CSCF 



EATF 



E-CSCF 



1. UE A is on an emergency call with PSAP through PS network. Call is anchored at EATF. 



2. UE A sends measurement reports to 
E-UTRAN, and the source 
E-UTRAN decides to trigger an SRVCC 
handover to the UTRAN/GERAN 



-1. PS bearer 



-3.INVITE(E-STN-SR)- 



-13. SIP 200 (OK) iNviTE- 
14. SIP ACK 



-18. SIP BYE- 
I 



-19. SIP 200 (OK)- 



■22a.CS bearer- 



4. SIP INVITE 
(E-STN-SR) * 



5 Remote leg Update 



12. SIP 
200 (OK) INVITE 



-15. SIP ACK-l 



—10. SIP ACK-*- 



-17. SIP BYE- 



-20. SIP 200 (OK)- 



-22b. PS bearep- 



6. SIP 
'reFNVITE 



9. SIP 200 (OK) 

relNVITE 



-16. SIP BYE-»« 




7. SIP 
relNVITE 
^ 8. SIP 200 _ 

(OK) relNVITE 



11. SIP ACK- 



Figure A.1 6.3-1 Signalling flow for emergency session transfer using SRVCC procedure 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. UE A is on an active emergency session with a PSAP 

There is an ongoing IP bearer between the UE A and the remote end PSAP. The call is achored at EATF. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSC Server initiates the session transfer with the E-STN-SR, refer to 
3GPPTS 23.237 [9]. 

3. SIP EWITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
table A.16.3-2 
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Table A.1 6.3-2: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl .visitl .net;branch=z9hG4bk731b87 
Max- Forwards : 70 

Route : <sip:icscfl. visitl. net ; lr> 
P-Asserted- Identity : <tel:+l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=visitl . net 
Privacy: none 

From: <tel : +1-237- 555- 1111> ; tag=171828 
To: <tel: +l-237-555-3333> 
Call -ID: Cb0 3a0s09a2sdfglkj4 90 334 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : mscl . homel . net > ; +sip . instance= " <urn : gsma : imei :9042 0156-025763-0>";+g. 3gpp . icsi- 
ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 
a = tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 



Request-URI: contains the E-STN-SR, as routed to the EATF 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

Contact: contains the "sip.instance" media feature tag as specified in IETF RFC 5626 [22] with a value formed 
fi-om an IMEI as defined in 3GPP TS 23.003 [12]. 

4. SIP EVVITE request 

The 1-CSCF routes the SIP INVITE request directly to the EATF by using the procedure defined in 
3GPP TS 23.228 [15] for PSI based application Server termination. 

NOTE 2: The use of indirect routing for PSI based Application Server Termination as described in 

3GPP TS 23.228 [15] in subclause 5.7.6 cannot be used for routing the SIP INVITE request to the EATF. 

5. Remote Leg Update 

The EATF based on the content of the "gr" parameter in the Contact header field correlates the SIP INVITE 
request to the local and remote call legs of the existing session between the UE A and the remote end. The EATF 
performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

6. SIP re-EWITE request (EATF to intermediate IM CN subsystem entities) -see example in table A.16.3-3 

TheEATF acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 

Table A.16.3-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

INVITE urn : service : SOS . fire SIP/2.0 

Via: SIP/2. 0/UDP esccasl . homel . net ;branch=z9hG4bKnas34r5 
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Max- Forwards : 68 

Route: <sip:ecscf 1 .homel .net : lr> 
P-Asserted-Identity: <tel: +l-237-555-llll> 

P-Charging-Function-Addresses : ccf= [5555: :b99 : c88 : d77 : e66] ; ccf= [5555: : a55 :b44 : c33 : d22] ; 

ecf = [5555 : : If f : 2ee : 3dd : 4ee] ; ecf = [5555 : : 6aa : 7bb : 8cc : 9dd] 
P- Charging- Vector : icid-value="BzyretyU0dm+602IrT5tAFrbHLso=023551034 " ; orig-ioi="type3homel .net " 
Privacy : none 

From: <sip :userl jiubliclOhomel .net> ; tag=17182 8 
To : <urn: service : sos . f ire> ; tag=232456 
Call-ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 

Contact : <sip :userl_publicl@homel .net ; gr=urn :uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6> ; +sip . instance= "<urn : gsma : imei : 9042 0156 -025763 -0>" 
Allow: 

Content -Type : Content -Length: 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 
t=0 

m=audio 3456 RTP/AVPF 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des : qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 
m=message TCP/MSRP 98 
a=accept- types : text/plain 



7. SIP re-INVITE request (E-CSCF to PSAP) 
E-CSCF forward the SIP re-INVITE request to the PSAP. 

8. SIP 200 (OK) response (PSAP to E-CSCF) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the PSAP has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 

SDP answer indicates that the resources are available. 

9. SIP 200 (OK) response (E-CSCF to EATF) 

E-CSCF forward the SIP 200 (OK) response to the SIP re-INVITE request to the EATF in the originating 
network. 

10-11. SIP ACK request (EATF to PSAP via IM CN subsystem entities) 

The EATF generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to 
the PSAP. 

12-13. SIP 200 (OK) response (EATF to interworking entities via IM CN subsystem entities) 

The E- sec AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 
(OK) response to the interworking entities. 

14-15. SIP ACK request (interworking entities to EATF via IM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward the SIP ACK 
request to the EATF. 

16-18: SIP BYE request (EATF to UE A via intermediate IM CN subsystem entities) 

The EATF terminates the source access leg, which was using the old IP-CAN, by sending a SIP BYE request to 
theUE A. 

19-21. SIP 200 (OK) response (UE A to E- SCC AS via intermediate IM CN subsystem entities) 
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Upon receiving the SIP BYE request over the old IP-CAN, the UE A sends a SIP 200 (OK) response over the 
old IP -CAN to the EATF. Subsequently, the UE A relinquishes all resources pertaining to the old IP-CAN. 

22a. CS bearer establishment (interworking entities to UE A) 

22b. IP bearer establishment (interworking entities to PSAP) 



A.1 7 Signalling flows for SRVCC in Alerting State 
A.17.1 Introduction 

The signalUng flows in the subclause demonstrate how sessions in alerting state can be transferred from PS to CS using 
SRVCC procedures. The following signalling flows are included: 

- subclause A.17.2 shows an example of PS to CS SRVCC transfer where the incoming call is in alerting phase. 

- subclause A. 17.3 shows an example of PS to CS SRVCC transfer where the outgoing call is in alerting phase. 

- subclause A. 17.4 shows an example of PS to CS SRVCC transfer where the incoming call is in alerting phase, 
but the user answers the call in the PS domain prior to the completion of the network handover procedures and 
the UE retuning to the CS domain. 

subclause A. 17.5 shows an example of PS to CS SRVCC transfer where the incoming call is in alerting phase, 
but the user answers the call in the PS domain prior to the completion of the network handover procedures but 
the handover to CS does not succeed. 

A.17.2 Session transfer for incoming call is in alerting phase using 
SRVCC procedure: PS to CS 

In the example flow at the figure A. 15. 2-1, SC UE A has an incoming audio session over PS bearer which is anchored 
at sec AS. The session is in alerting phase. Based upon measurement reports sent from the UE to E-UTRAN, the 
source E-UTRAN decides to trigger a SRVCC handover to CS access. 
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Figure A.1 7.2-1: PS-CS SRVCC, incoming call in alerting phase 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1. SC UE A has received an incoming call and is in Ringing State 

The incoming call has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and SC 
UE A has sent a 180 (Ringing) response. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPP TS 23.237 [9]. The UE continues ringing. 

3. SIP INVITE request transferring the session (MSC server to intermediate EM CN subsystem entities) - see 
example in table A.17.2-1 

The MSC server sends an initial SIP INVITE request with STN SR 

Table A.17.2-1 : SIP INVITE request (MSC server to intermediate IIUI CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl .visitl .net;branch=z9hG4bk731b87 
Max- Forwards : 70 

Route : <sip:icscfl. visitl. net ; lr> 
P-Asserted- Identity : <tel :+l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=visitl . net 
Privacy: none 

From: <tel : +1-237- 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-3333> 
Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 34 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : mscl . homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> ; +g . 3gpp . icsi- 

ref ="urn%3Aurn-7%3gpp-service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Recv- Inf o : g . 3gpp . state -and- event- info 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



Request-URI: contains the STN-SR. 

SDP: The SDP contains set of codecs supported by the MGW. 
4. SIP INVITE request transferring the session (intermediate EM CN subsystem entities to SCC AS) 

The SIP INVITE request is routed towards the SCC AS, based on filter criteria in S-CSCF. 
4a. Remote Leg Update 



ETSI 



3GPP TS 24.237 version 10.2.0 Release 10 



162 



ETSI TS 124 237 VI 0.2.0 (2011-04) 



The sec AS correlates SIP INVITE request to the local and remote call legs of the existing session between the 
UE A and the remote end. The SCC AS performs the Remote Leg update by sending the SIP sending a SIP 
UPDATE request towards the Remote Leg. 

5. SIP UPDATE request (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS acting as a B2BUA generates a SIP UPDATE request based upon the received SIP INVITE request 
and the information previously stored against this session . 

6. SIP UPDATE request (Intermediate EM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE B. 

7. SIP 200 (OK) response (far end UE to Intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the far end sends a 
SIP 200 (OK) response. 

8. SIP 200 (OK) response (Intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

9. SIP 183 (Session Progress) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS sends a 183 (Session Progress) containing the SDP answer as received from the far end UE. The 
SDP answer indicates that resources are available. The SIP 183 (Session Progress) will contain a Recv-Info 
header field set to g.3gpp.state-and-event-info. 

10. SIP 183 (Session Progress) response (Intermediate EM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the 183 (Session Progress) to the MSC server. 

11. SIP PRACK request (MSC server to Intermediate IM CN subsystem entities) 
The MSC acknowledges the receipt of the 183 Session Progress.. 

12. SIP PRACK request (Intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem forward the SIP PRACK request to the SCC AS. 

13. SIP 200 (OK) response (SCC AS to Intermediate EM CN subsystem entities) 
The SCC AS acknowledges the PRACK 

14. SIP 200 (OK) response (Intermediate EM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forwards the SIP 200 (OK) reponse to the MSC server. 

15. SIP INFO request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.17.2-2 

Table A.17.2-2: INFO request (SCC AS to intermediate IM CN subsystem entities) 



INFO sip :mscl . homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a76 5-00a0c91e6bf 6SIP/2 . 
Via SIP/2. 0/UDP sip : sccasl . homel . net ;branch=z9hG4bK332b23 . 1 
Max-Forwards: 68 

Route : <sip : scscf 1 . homel . net ; lr> 
From: <tel: +1-237- 555- 3333 >; tag=314159 
To: <tel : +1-237- 555- llll>;tag=171828 
Call -ID: Cb0 3a0s0 9a2sdfglkj4 90334 
Cseq: 129 INFO 

Info- Package : g . 3gpp . state -and- event- info 

Content -Type : application/vnd. 3gpp . s t ate -and- event -info+xmls 
Content -Length: 

<?xml version="l . 0" encoding="UTF-8"?> 
< state- and- event -info> 

< state -info>early</ state -info> 

<direction>receiver< /direct ion> 
</state-and-event-inf o> 
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16. SIP INFO request (Intermediate EM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the MSC server. The MSC server is 
aware that the call that is transferred is in terminating alerting state. 

17. SIP 200 (OK) response (MSC server to Intermediate IM CN subsystem entities) 

The MSC server acknowledges the receipt of the SIP INFO request. 

18. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forwards the SIP 200 (OK) response to the SCC AS. 

19. MSC goes in CaU received state 

The MSC enters Call received state due to the information received in the INFO request. 
20a. User answers the call 

20. CS Connect Message from SC UE A to MSC server 

The SC UE A accepts the call and sends CS Connect Message. 

21. SIP INFO request (MSC server to intermediate IM CN subsystem entities) - see example in 
table A.17.2-3 

Table A.17.2-3: INFO request (SCC AS to intermediate IM CN subsystem entities) 



INFO sip : sccasl . homel . net ;gr SIP/2.0 

Via: SIP/2. 0/UDP mscl .visitl .net;branch=z9hG4bk731b87 
Max-Forwards: 68 

Route : <sip : scscf 1 . homel . net ; lr> 
From: <tel : +1-237- 555- 1111 >; tag=17182 8 
To: <tel: +l-237-555-3333>;tag=171828 
Call -ID: Cb0 3a0s09a2sdfglkj4 90334 
Cseq: 130 INFO 

Info-Package: g. 3gpp . state-and-event-info 

Content -Type : application/vnd. 3gpp . s tat e- and- event -info+xmls 
Content -Length: 

<?xml version="l . 0" encoding="UTF-8"?> 

< state- and- event -info> 

<event>call -accepted</event> 
</state-and- event -info> 



22. SIP INFO request (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the SCC AS. The SCC AS gets 
informed that the SC UE A has accepted the call. 

23 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acknowledges the receipt of the INFO request indicating that the SC UE A has accepted the call 

24 SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server) 
The SIP 200 (OK) response is forwarded to the MSC server. 

25 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response to indicate to the far end that the SC UE A has accepted the call. 

26 SIP 200 (OK) response (Intermediate IM CN subsystem entities to far end) 
The SIP 200 (OK) response is forwarded to the far end) 

27 SIP ACK request (far end to intermediate IM CN subsystem entities) 

The far end UE acknowledges the SIP 200 (OK) response received from SCC AS 
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28 SIP ACK request (Intermediate EM CN subsystem entities to SCC AS) 

The SIP ACK request is forwarded to the SCC AS. 

29 SIP 200 (OK) response (SCC AS to intermediate EM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response to indicate the successful access transfer to the MSC server. 

30 SIP 200 (OK) response (Intermediate IM CN subsystem entities to far end) 
The SIP 200 (OK) response is forwarded to the MSC server. 

31 CS Connect Ack (MSC server to SC UE A) 

32 SIP ACK request (MSC server to intermediate EM CN subsystem entities) 

MSC server acknowledges the 200 OK received from SCC AS 

33 SIP ACK request (Intermediate EM CN subsystem entities to SCC AS) 

The SIP ACK request is forwarded to the SCC AS. 
34-41 CANCEL Processing 

The SCC AS cancels the SIP dialog towards the SC UE 

A. 17.3 Session transfer for originating call is in alerting phase 
using SRVCC procedure: PS to CS 

In the example flow at the figure A.17.3-1, SC UE A has invited for an originating audio session over PS bearer which 
is anchored at SCC AS. The session is in alerting phase. Based upon measurement reports sent from the UE to E- 
UTRAN, the source E-UTRAN decides to trigger a SRVCC handover to CS access. 
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Figure A.17.3-1: PS-CS SRVCC, incoming call in alerting phase 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. SC UE A has setup an outgoing call 

The outgoing call has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and SC 
UE A has received a SIP 180 (Ringing) response. 
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2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSG server initiates the session transfer with the STN-SR, refer to 
3GPP TS 23.237 [9]. The UE continues ringing. 

3. SIP INVITE request transferring the session (MSG server to intermediate IM GN subsystem entities) - see 
example in table A.17.3-1 

The MSG server sends an initial SIP INVITE request with STN-SR 

Table A.17.3-1 : SIP INVITE request (MSC server to intermediate IM CN subsystem entities) 

INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.visitl.net;branch=z9hG4bk731b87 

Max- Forwards : 70 

Route : <sip:icscfl.visitl. net ; lr> 
P-Asserted- Identity: <tel : +l-237-555-llll> 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig-ioi=visitl .net 
Privacy: none 

From: <tel : +1-237- 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-3333> 
Call -ID: Cb0 3a0s09a2sdfglkj4 90334 
Cseq: 12 7 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7% 3gpp- service . ims . icsi . mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : mscl . homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 > ; +g . 3gpp . icsi- 

ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Recv- Info : g . 3gpp . state -and- event -info 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa:bbb: ccc :eee 
t=0 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des : qos mandatory local sendrecv 
a=des : qos none remote sendrecv 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:9G telephone-event 
a=maxptime : 2 



Request-URI: contains the STN-SR. 

SDP: The SDP contains set of codecs supported by the MOW. 

4. SIP INVITE request transferring the session (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE is routed towards the SGG AS, based on filter criteria in S-GSGF. 
4a. Remote Leg Update 

The SGG AS correlates SIP INVITE request to the local and remote call legs of the existing session between the 
UE A and the remote end. The SGG AS performs the Remote Leg update by sending SIP UPDATE request 
towards the Remote Leg. 

5. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities) 

The SGG AS acting as a B2BUA generates a SIP UPDATE request based upon the received SIP INVITE request 
and the information previously stored against this session. 
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6. SIP UPDATE request (Intermediate EM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE B. 

7. SIP 200 (OK) response (far end UE to Intermediate EM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the far end sends 200 
OK. 

8. SIP 200 (OK) response (Intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 

9. SIP 183 (Session Progress) response (SCC AS to Intermediate EM CN subsystem entities) 

The SCC AS sends a 183 (Session Progress) containing the SDP answer as received from the far end UE. The 
SDP answer indicates that resources are available 

10. SIP 183 (Session Progress) response (Intermediate EM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the 183 (Session Progress) to the MSC server. 

11. SIP PRACK request (MSC server to Intermediate IM CN subsystem entities) 
The MSC acknowledges the receipt of the 183 Session Progress. 

12. SIP PRACK request (Intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP PRACK request to the SCC AS. 

13. SIP 200 (OK) response (SCC AS to Intermediate EM CN subsystem entities) 
The SCC AS acknowledges the PRACK 

14. SIP 200 (OK) response (Intermediate EM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) reponse to the MSC server. 

15. SIP INFO request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.17.3-2 

Table A.17.3-2: INFO request (SCC AS to intermediate IM CN subsystem entities) 



INFO sip :mscl . homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a76 5-00a0c91e6bf 6SIP/2 . 
Via SIP/2. 0/UDP sip isccasl. homel. net ;branch=z9hG4bK332b23.1 
Max- Forwards : 6 8 

Route : <sip : scscf 1 . homel . net ; lr> 
From: <tel: +1-23 7- 555 - 3 3 3 3 > ; tag=3 14159 
To: <tel : +1-237- 555- llll>;tag=171828 
Call -ID: Cb0 3a0s09a2sdfglkj4 90334 
Cseq: 129 INFO 

Info- Package : g . 3gpp . state -and- event- info 

Content-Type: application/ vnd. 3gpp . state-and-event-inf o+xmls 
Content -Length: 

<?xml version^ " 1 . " encoding="UTF-8"?> 
< state -and- event -info> 

< state - info>early</ state - info 

<direction>initiator< /direct ion> 
</state-and-event-inf o> 



16. SIP EVFO request (Intermediate EM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the MSC server. The MSC server is 
aware that the call that is transferred is in originating alerting state. 

17. SIP 200 (OK) response (MSC server to Intermediate EM CN subsystem entities) 

The MSC Server acknowledges the receipt of the SIP INFO request. 
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18. SIP 200 (OK) response (Intermediate EM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forwards the SIP 200 (OK) response to the SCC AS. 

19. MSG goes in Call delivered state 

The MSC enters Call delivered state due to the information received in the SIP INFO request. 

20. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 
The UE B accepts the call and sends 200 (OK) response. 

21. 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 
The 200 (OK) response is forwarded to SCC AS. 

22 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends the 200 (OK) response to indicate that the terminating UE B has accepted the call. 

23 200 (OK) response (Intermediate IM CN subsystem entities to MSC server) 
The 200 (OK) response is forwarded to the MSC server. 

24 CS CONNECT (MSC server to SC UE A) 

The MSC server indicates to the SC UA A that the far end has accepted the call. 

25 CS CONNECTACK (MSC server to SC UE A) 
SC UE A acknowledges the CS CONNECT. 

26 SIP ACK request (MSC server to intermediate IM CN subsystem entities) 
The MSC server acknowledges the SIP 200 (OK) response received from SCC AS 

27. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS) 
The SIP ACK request is forwarded to the SCC AS. 

28 SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acknowledges the SIP 200 (OK) response received towards far end.. 

29 SIP ACK request (Intermediate IM CN subsystem entities to far end) 
The SIP ACK request is forwarded towards the far end. 

30 - 33 The SCC AS releases the original source leg towards the SC UE A 

The SCC AS sends a SIP 404 (Not Found) response in order to release to original source dialog towards the SC 
UFA 

A.17.4 User answers in PS domain; Handover to CS successful 

In the example flow in figure A. 17.4-1, SC UE A has an incoming audio session over PS bearer which is anchored at 
SCC AS. The session is in alerting phase. Based upon measurement reports sent from the UE to E-UTRAN, the source 
E-UTRAN decides to trigger a SRVCC handover to CS access. However the user answers the call in E-UTRAN and the 
SC UE sends a SIP 200 (OK) response to the SCC AS. It this scenario the handover to CS is successful. 
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Figure A.1 7.4-1 : SIP 200 OK from SC UE received by SCC AS: Handover to CS successful 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalUng flow. 

1 SC UE A has received an incoming call and is in Ringing State 

The incoming call has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and 
SC UE A has sent a 180 (Ringing) response. 

2-5 MSG server sends session transfer request. SCC AS sends SIP UPDATE to update the remote end 

These steps are identical to steps 3-6 in subclause A.17.2. 

6 User answers the call when the UE is still in the source E-UTRAN access 

7-8 SIP 200 (OK) response (SC UE to intermediate IM CN subsystem entities to SCC AS) 

The SCC AS performs no additional actions on receipt of the SIP 200 (OK) i.e. the SCC AS does not confirm 
reception of the SIP 200 (OK) response with SIP ACK request and performs no actions on dialogs with UE B 
and with MSC server. 

9-21 Continuation of procedure for SRVCC in Alerting Phase 

These steps are identical to steps 7-19 in subclause A.17.2. 

22 UE receives H/O command from source E-UTRAN 

23 UE retunes to 3G 

24 CS Connect Message from SC UE A to MSC server 

The SC UE A sends CS Connect Message as it did not receive a SIP ACK to the SIP 200 (OK) sent in step 7. 
25-37 Continuation of procedure for SRVCC in Alerting Phase 

These steps are identical to steps 21-33 in subclause A.17.2. 
38-39 SIP ACK request (SCC AS to intermediate IM CN subsystem entities to SC UE) 

The SCC AS confirms reception of the SIP 200 (OK) response received in message 8. 
40 Release original SIP dialog 

The SCC AS releases the SIP dialog towards the SC UE. 

A.1 7.5 User answers in PS domain; Handover to CS not 
successful 

In the example flow in figure A. 17.5-1, SC UE A has an incoming audio session over PS bearer which is anchored at 
SCC AS. The session is in alerting phase. Based upon measurement reports sent from the UE to E-UTRAN, the source 
E-UTRAN decides to trigger a SRVCC handover to CS access. However the user answers the call in E-UTRAN and 
the SC UE sends a SIP 200 (OK) response to the SCC AS. In this scenario the handover to CS is not successful because 
the source E-UTRAN decides to terminate the handover procedure before its completion. In a similar scenario, the UE 
can also encounter a failure after it receives the handover command but does not successfully transition to 3GPP 
UTRAN/GERAN. 
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Figure A.1 7.5-1 : SIP 200 OK from SC UE received by SCC AS: Handover cancelled 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 
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1 SC UE A has received an incoming call and is in Ringing State 

The incoming call has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and 

SC UE A has sent a 180 (Ringing) response. 

2-18 Continuation of procedure for SRVCC in Alerting Phase 

These steps are identical to steps 3-19 in subclause A. 17.2. 

19 User answers the call when the UE is still in the source E-UTRAN access 

20-21 SIP 200 (OK) response (SC UE to intermediate EM CN subsystem entities to SCC AS) 

The SCC AS performs no additional actions on receipt of the SIP 200 (OK) response i.e. the SCC AS does 
not confirm reception of the SIP 200 (OK) response with SIP ACK request and performs no actions on 
dialogs with UE B and with MSC server. 

9-21 Continuation of procedure for SRVCC in Alerting Phase 

These steps are identical to steps 7-19 in subclause A. 17.2. 

22 SC UE A receives SRVCC Handover Cancelled command from source E-UTRAN 

23-26 SIP UPDATE request (SC UE to intermediate EM CN subsystem entities to SCC AS to UE B) 

SC UE A sends a SIP UPDATE request with a SDP offer, including the media characteristics as used in the 

existing dialog and with a Reason header field containing protocol "SIP" and reason parameter "cause" with 
value "487" as specified in IETF RFC 3326 [57] and with reason-text set to "handover cancelled". 

NOTE 2: In the case that the handover command was received but the UE did not transition to the CS domain, the 
UE sends the SIP UPDATE request as described above, but with reason-text set to "failure to transition to 
CS domain". 

27-30 SIP 200 (OK) response to the SIP UPDATE request (UE B to SCC AS to intermediate EM CN 
subsystem entities to SC UE A) 

31-32 SIP 480 (Temporary Unavailable) response (SCC AS to intermediate EM CN subsystem entities to 
MSC server) 

The SCC AS responds to the MSC server with a SIP 480 (Temporary Unavailable) response which indicates 
that it is unable to go ahead with the session transfer. 

33-36 Continuation of procedure for SRVCC in Alerting Phase 

These steps are identical to steps 25-28 in subclause A. 17.2. The SCC AS sends SIP 200 (OK) response to 
UE B as final confirmation to the original session and UE B sends SIP ACK request back to the SCC AS. 

37-38 SIP ACK request (SCC AS to intermediate EM CN subsystem entities to SC UE) 

The SCC AS confirms reception of the SIP 200 (OK) response received in message 21. 

A. 17.6 Session transfer for originating call is in alerting phase with 
forked responses using SRVCC procedure: PS to CS 

In the example flow at the figure A. 17. 6-1, SC UE A initiates an originating audio call over PS bearer which has 
received several forked responses. The call is anchored at SCC AS and in alerting phase. Based upon measurement 
reports sent from the UE to E-UTRAN, the source E-UTRAN decides to trigger a SRVCC handover to CS access. 
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Figure A.17.6-1: PS-CS SRVCC, incoming caii in alerting phase with forked responses 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1-4. SIP INVITE request (SC UE A to Terminating network Intermediate IM CN subsystem entities) - see 
example in table A.17.6-1 
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SC UE A sends an outgoing call to the terminating party. The call has been anchored at the SCC AS. 
Table A.1 7.6-1 : SIP INVITE request (UE to Intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 70 

Route : <sip:pcscf 1 . visited2 .net : 7531 ; Ir ; comp=sigcomp> , <sip : orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip:userl_publicl@homel .net> 

P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi .mmtel 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net> ; tag=17182 8 
To: <tel:+l-212-555-2222> 
Call-ID: Cb03a0s09a2sdfglkj490333 
Cseq: 12 7 INVITE 
Require: sec-agree 

Supported: precondition, lOOrel, gruu 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321 ; port- 
c=8642; port-s=7531 

Contact : <sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6 ;comp=sigcomp>; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 
s=- 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des : qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 
a=rtpmap:96 telephone-event 



5. SIP INVITE request (Terminating network Intermediate EM CN subsystem entities to UE B) 

The Terminating network Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE, 
determine that the SIP INVITE request should be forked, and send the SIP INVITE request to UE B. 

6. SIP INVITE request (Terminating network Intermediate IM CN subsystem entities to UE C) 

The Terminating network Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE, 
determine that the SIP INVITE request should be forked, and send the SIP INVITE request to UE C. 

7-11. SIP 180 (Ringing) response to SIP INVITE request (UE B to UE A though SCC AS) 

The remote UE B responds with SIP 180 (Ringing) response. And a dialog (dialog I) has been established 
between UE A and UE B. 
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Table A.1 7.6-7: SIP 180 (Ringing) response (UE B to Terminating network Intermediate IIUI CN 

subsystem entities) 



SIP/2.0 180 Ringing 

Record-Route : <sip:pcscf 1 . visitedl .net ; lr> 
Via : 

Max-Forwards: 60 

P-Asserted- Identity: <tel : +l-212-555-2222> 

Privacy: 

From : 

To: <tel : +l-212-555-2222>; tag=aaa 

Call-ID: 

Cseq: 

Require : 
Supported : 

Contact : <sip:user2_publicl®home2 . net ; gr=urn :uuid: 2ad8950e-4 8a5-4a74 - SdSS- 
adVSccVf c74>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Allow: 

Content-Type : 
Content - Length : 

v=0 

o=- 462346 5654 IN IP6 1234 : : 55 : 66 : 77 : 88 
s = - 

C=IN IP6 1234: :55:66:77:88 
t = 

m=audio 4456 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local none 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des : qos mandatory remote sendrecv 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap : 96 telephone-event 



12-16. SIP 180 (Ringing) response to SIP INVITE request (UE C to UE A though SCC AS) 

The remote UE C responds with SIP 180 (Ringing) response. And a dialog (dialog 2) has been established 
between UE A and UE B. 
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Table A.17.6-12: SIP 180 (Ringing) response (UE B to Terminating network Intermediate IIUI CN 

subsystem entities) 



SIP/2.0 180 Ringing 

Record-Route : <sip:pcscf 1 . visitedl .net ; lr> 
Via : 

Max-Forwards: 60 

P-Asserted- Identity: <tel : +l-212-555-2222> 

Privacy: 

From : 

To: <tel:+l-212-555-2222>; tag=bbb 

Call-ID: 

Cseq: 

Require : 
Supported : 

Contact : <sip:user2_publicl®home2 . net ; gr=urn :uuid: 2ad8950e-4 8a5-4a74 - SdSS- 
adVSccVf c74>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Allow: 

Content-Type : 
Content - Length : 

v=0 

o=- 462346 5654 IN IP6 1234 : : 55 : 66 : 77 : 88 
s = - 

C=IN IP6 1234: :55:66:77:88 
t = 

m=audio 4456 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local none 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des : qos mandatory remote sendrecv 
a= r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap : 96 telephone-event 



17. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPP TS 23.237 [9]. The UE continues ringing. 

18. SIP INVITE request transferring the session (MSC server to originating network intermediate IM CN 
subsystem entities) - see example in table A.17.6-18 

The MSC server sends an initial SIP INVITE request with STN-SR 

Table A.17.6-18: SIP INVITE request (MSC server to intermediate IM CN subsystem entities) 

INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl .net ;branch=z9hG4bk731b87 
Max- Forwards : 70 

Route : <sip:icscfl. visitl .net ; lr> 
P-Asserted- Identity: <tel : +1-23 7-555 -1111> 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig-ioi=visitl .net 
Privacy: none 

From: <tel : +1-23 7-555 -1111> ; tag=17182 8 
To: <tel:+l-237-555-3333> 
Call-ID: Cb03a0s09a2sdfglk;j490334 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
P-Asserted- Service : urn : urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip:mscl . homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6>; +g. 3gpp. icsi- 
ref = "urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Recv-Inf o : g . 3gpp . state-and-event-inf o 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 
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t=o 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode - set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 



Request-URI: contains the STN-SR. 

SDP: The SDP contains set of codecs supported by the MGW. 

19. SIP INVITE request transferring the session (intermediate EM CN subsystem entities to SCC AS) 
The SIP INVITE is routed towards the SCC AS, based on filter criteria in S-CSCF. 

20. Remote Leg Update 

The SCC AS correlates SIP INVITE request to the local and remote call legs of the existing session between the 
UE A and the remote end. Since the existing session has forked responses, more than one dialog can be 
correlated to the SIP INVITE due to STN-SR The SCC AS performs the Remote Leg update towards all the 
correlated dialogs. 

21-23. SIP UPDATE request (SCC AS to UE B through Intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA generates a SIP UPDATE request towards dialog 1 to remote UE B based upon 
the received SIP INVITE request in step 19. 

24-26. SIP 200 (OK) response (Remote UE B to SCC AS through Intermediate EM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the remote UE B 
sends 200 OK. 

27-28. SIP 183 (Session Progress) response (SCC AS to MSC server through Intermediate EM CN subsystem 
entities) 

The SCC AS sends a 183 (Session Progress) containing the SDP answer as received from the remote UE B to the 
MSC server. The SDP answer indicates that resources are available 

29-30. SIP PRACK request (MSC server to SCC AS through Intermediate EM CN subsystem entities) 

The MSC acknowledges the receipt of the 183 Session Progress by sending SIP PRACK request to the SCC AS. 
31-32. SIP 200 (OK) response (SCC AS to MSC server through Intermediate EM CN subsystem entities) 

The SCC AS acknowledges the PRACK with the SIP 200 (OK) reponse to the MSC server. 

33. SIP INFO request (SCC AS to Originating network intermediate EM CN subsystem entities) - see example 
m table A.17.3-2 

Table A.17.3-2: INFO request (SCC AS to intermediate IM CN subsystem entities) 



INFO sipimscl .homel.net;gr=urn:uuid:f 81d4fae-7dec-lld0-a765-00a0c91e6bf 6SIP/2 . 
Via SIP/2. 0/UDP sip:sccasl.homel.net;branch=z9hG4bK332b23.1 

Max-Forwards: 68 

Route : <sip : scscf 1 . homel . net ; lr> 
From: <tel: +1-237- 555- 3333 >; tag=314159 
To : <tel : +l-237-555-llll>; tag=171828 
Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 34 
Cseq: 129 INFO 

Info -Package : g . 3gpp . state -and- event- info 

Content-Type: application/ vnd. 3gpp . state-and-event-inf o+xmls 
Content -Length: 
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<?xml version="l . 0" encoding="UTF-8"?> 
<state-and-event-inf o> 

<state-info>early< /state -info 

<direction>initiator< /direct ion> 
</state-and-event-inf o> 

34. SIP EVFO request (Intermediate EM CN subsystem entities to MSC server) 

The intermediate IM CN subsystem entities forward the SIP INFO request to the MSC server. The MSC server is 
aware that the call that is transferred is in originating alerting state. 

35. SIP 200 (OK) response (MSC server to Intermediate IM CN subsystem entities) 

The MSC Server acknowledges the receipt of the SIP INFO request. 

36. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forwards the SIP 200 (OK) response to the SCC AS. 

37-39. SIP UPDATE request (SCC AS to UE C through Intermediate IM CN subsystem entities) 

In parallel with step 21, the SCC AS acting as a B2BUA generates a SIP UPDATE request towards dialog 2 to 
remote UE C based upon the received SIP INVITE request in step 19. 

40-42. SIP 200 (OK) response (Remote UE C to SCC AS through Intermediate IM CN subsystem entities) 

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the remote UE C 
sends 200 OK. 

43-44. SIP 183 (Session Progress) response (SCC AS to MSC server through Intermediate IM CN subsystem 
entities) 

The SCC AS sends a SIP 183 (Session Progress) containing the SDP answer as received from the remote UE C 
to the MSC server. The SDP answer indicates that resources are available 

45-46. SIP PRACK request (MSC server to SCC AS through Intermediate IM CN subsystem entities) 

The MSC acknowledges the receipt of the 183 Session Progress by sending SIP PRACK request to the SCC AS. 
47-48. SIP 200 (OK) response (SCC AS to MSC server through Intermediate IM CN subsystem entities) 

The SCC AS acknowledges the PRACK with the SIP 200 (OK) reponse to the MSC server. 
49. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

In this example, the remote UE B accepts the call first and sends 200 (OK) response. 
50-51. 200 (OK) response (Intermediate EM CN subsystem entities to SCC AS) 

The 200 (OK) response is forwarded to SCC AS. 
52-53 200 (OK) response (SCC AS to MSC server through Intermediate EM CN subsystem entities) 

The 200 (OK) response is forwarded to the MSC server based on the route estabhshed during step 24-28. 

54 CS CONNECT (MSC server to SC UE A) 

The MSC server indicates to the SC UA A that the remote UE B has accepted the call. 

55 CS CONNECTACK (MSC server to SC UE A) 
SC UE A acknowledges the CS CONNECT. 

56-60. SIP ACK request (MSC server to remote UE B through intermediate EM CN subsystem entities) 
The MSC server acknowledges the SIP 200 (OK) response by sending The SIP ACK request to remote UE B. 
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61 SIP CANCEL request (Terminating network intermediate IM CN subsystem entities to remote UE C) 

The intermediate IM CN subsystem entities send the SIP CANCEL request to remote UE C to release the call 
towards remote UE C. 

62 SIP 200 (OK) response to SIP CANCEL request (UE-3 to Intermediate IM CN subsystem entities) 
Remote UE C responds SIP 200 (OK) response to the SIP CANCEL request. 

63-66 Tlie SCC AS releases tlie original source leg towards the SC UE A 

The SCC AS sends a SIP 404 (Not Foimd) response in order to release to original source dialog towards the SC 
UEA 

A.1 8 Signalling flows for PS to CS Access Transfer: 
SRVCC enhancements using ATCF 

A.1 8.1 Introduction 

The siginalling flows in the subclause demonstrate the PS to CS access transfer for SRVCC enhancements using ATCF. 
The following signalling flows are included: 

- subclause A. 18.2 shows an example of PS to CS access transfer for SRVCC enhancements using ATCF and 
without media anchored. 

- subclause A.18.3 shows an example of PS to CS access transfer for SRVCC enhancements using ATCF and 
media anchored. 

A.1 8.2 Signalling flows for PS to CS Access Transfer: SRVCC 
enhancements using ATCF and without media anchored 

The signalling flow shown in figure A. 18.2-1 gives an example for PS to CS access transfer when using ATCF 
enhancements and without media anchored. In this case, the ATCF has been included in the path for subsequent 
transactions created at registration, but media has not been anchored in ATGW. 
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Figure A.1 8.2-1 Signalling flows for PS to CS access transfer: SRVCC enhancements using ATCF and 

without media anchored 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE A is on an active session with UE B 

There is an ongoing PS bearer between the UE A and the remote end UE B. The media is not anchored at 
ATGW. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPPTS 23.216 [49]. 

3. SIP INVITE request (MSC server to ATCF)-see example in table A.18.2-3 

Table A.18.2-3: SIP INVITE request (MSC server to ATCF) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl .net ;branch=z9hG4bk731b87 
Max- Forwards : 70 

P-Asserted- Identity: <tel:+l-237-555-2222> 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig-ioi=visitl .net 
Privacy: none 

From: <tel : +1-23 7-555 -1111> ; tag=17182 8 
To: <tel: +l-237-555-3333> 
Call- ID: Cb03a0s09a2sdfglkj490334 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
P-Asserted- Service : urn : urn- 7 : 3gpp- service . ims .icsi .mmtel 
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Contact : <sip:mscl .homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6>; +g. 3gpp. icsi- 

ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 
t=0 

m=audio 3456 RTP/AVP 97 96 
a = tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxpt ime : 2 



Request-URI: contains the STN-SR, as routed to the ATCF. 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

4-5. SIP EWITE request (ATCF to SCC AS via I-CSCF)- see example in table A.18.2-4 

Since the media has not been anchored at the ATGW, the ATCF forwards the SIP INVITE request to the SCC 
AS by replacing the request URI to the stored ATU-STI. 

Table A.18.2-4: SIP INVITE request (ATCF to I-CSCF) 



INVITE sip:AUT-STIl@sccas. homel. net SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl .net ;branch=z9hG4bk731b87 

Max- Forwards : 70 

P-Asserted- Identity: <tel : +1-23 7 - 555 -2222> 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig-ioi=visitl .net 
Privacy: none 

From: <tel : +1-237-555- 1111 >; tag=17182 8 
To: <tel: +l-237-555-4444> 
Call-ID: Cb03a0s09a2sdfglkj 490334 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
P-Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip:mscl . homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6>; +g. 3gpp. icsi- 
ref = "urn%3Aurn- 7% 3gpp- service . ims .icsi .mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : eee 

s= 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
a = tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a= r tpmap :96 telephone- event 
a=maxpt ime : 2 
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6-7. SIP re-EWITE request (SCC AS to UE B via S-CSCF) 

The SCC AS based on the content of the C-MSISDN correlates the SIP INVITE request to the local and remote 
call legs of the existing session between the UE A and the remote end. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the Remote Leg. 

8-9. SIP 200 (OK) response (UE B to SCC AS via S-CSCF) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

10-11. SIP ACK request (SCC AS to UE B via S-CSCF) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

12-13. SIP 200 (OK) response (SCC AS to ATCF via I-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the ATCF. 

14. SIP 200 (OK) response (ATCF to MSC server) 

The ATCF generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 

response towards the MSC server. 

15. SIP ACK request (MSC server to ATCF) 

The MSC server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the ATCF. 
16-17. SIP ACK request (ATCF to SCC AS via I-CSCF) 

The ATCF generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 

18-21. SIP BYE request (SCC AS to UE via I-CSCF, ATCF and P-CSCF) 

The SCC AS terminates the source access leg, which was using the old IP-CAN, by sending a SIP BYE request 
to the UE A. 

22-24. SIP 200 (OK) response (UE A to SCC AS via P-CSCF, ATCF and I-CSCF) 

Upon receiving the SIP BYE request over the old IP-CAN, the UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes aU resources pertaining to the old IP-CAN. 

A.18.3 Signalling flows for PS to CS Access Transfer: SRVCC 
enhancements using ATCF and media anchored 

The signalling flow shown in figure A. 18.3-1 gives an example for PS to CS access transfer for SRVCC enhancements 
using ATCF and media anchored. In this case, the media is anchored in ATGW and ATCF has been included in the path 
for subsequent transactions created at registration. 
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Figure A.1 8.3-1 Signalling flows for PS to CS access transfer: SRVCC enhancements using ATCF and 

media anchored 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalhng flow. 

1. UE A is on an active session with UE B 

There is an ongoing IP bearer between the UE A and the remote end UE B. The media is anchored at ATGW. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 
3GPP TS 23.216 [49]. 

3. SIP INVITE request (MSC server to ATCF)-see example in table A.18.3-3 

Table A.18.3-3: SIP INVITE request (MSC server to ATCF) 



INVITE tel: -fl-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl .visitl .net;branch=z9hG4bk731b87 
Max-Forwards: 70 

P- Asserted- Identity: < tel : 23 7- 555-2222 > 

P -Charging- Vector : icid-value="AyretyU0dm-f602IrT5tAFrbHLso=023551024 " ;orig-ioi=visitl .net 

Privacy: none 

From: <tel : 4-1-23 7- 555- 1111 >; tag=17182 8 
To: <tel: -fl-237-555-3333> 
Call -ID: Cb03a0s09a2sdfglkj4 90334 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : mscl . homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 > ; +g . 3gpp . icsi- 

ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content -Type : application/sdp 
Content-Length: (...) 

v=0 
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o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 
s= 

c=IN IP6 5555 :: aaa: bbb: ccc : eee 
t=0 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des : qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



Request-URI: contains the STN-SR, as routed to the ATCF. 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

P-Asserted-Identity: the C-MSISDN of the served UE. 

4. Configure ATGW (ATCF to ATGW) 

Upon receiving the access transfer message, the ATCF correlates the transferred session using C-MSISDN. The 
ATCF updates the ATGW by replacing the existing PS access leg media path information with the new CS 
access leg media path information, by sending a Configure ATGW message to ATGW. 

5. Configure ATGW ACK (ATGW to ATCF) 

The ATGW sends Configure ATGW Acknowledgment message back to ATCF. 

6. SIP 200 (OK) response (ATCF to MSC server) 

The ATCF sends the SIP 200 OK response to the MSC server with the media information allocated by the 
ATGW during session establish procedure. 

7. SIP ACK request (MSC server to ATCF) 

8. SIP INVITE request (ATCF to I-CSCFs)-see example in table A.18.3-8 

After receiving the access transfer message, the ATCF re-establishes the communication with the SCC AS and 
updates the SCC AS that the transfer has taken place by sending a new SIP INVITE request to the SCC AS using 
the stored ATU-STI. As there is no update in the SDP information, no remote end update will be performed. 

Table A.18.3-8: SIP INVITE request (ATCF to l-CSCF) 



INVITE sip:AUT-STIl@sccas. homel.net SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl .net ;branch=z9hG4bk731b87 

Max- Forwards : 70 

P-Asserted- Identity: <tel : +1-23 7 - 555 -2222> 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig-ioi=visitl .net 
Privacy: none 

From: <tel : +1-237-555-3333 >; tag=171828 
To: <tel: +l-237-555-4444> 
Call- ID: Cb03a0s09a2sdfglkj 490334 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Target -Dialog: me03aOs09a2sdf gjkl491777 ; to-tag=774321 ; f rom-tag=64727891 
Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
P-Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip:mscl . homel . net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 > ; +g. 3gpp. icsi- 

ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ggg 
s= 
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c=IN IP6 5555 : :aaa:bbb: ccc :ggg 
t=0 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des : qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a = r tpmap : 9 7 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



Request-URI: contains the ATU-STI, as routed to the SCC AS. 
Target-Dialog: specifies that the existing dialog is related with this request. 
P-Asserted-Identity: the C-MSISDN of the served UE. 
SDP: the media information at ATGW. 

9. SIP INVITE request (I-CSCF to SCC AS) 

The I-CSCF forwards the SIP INVITE request to the SCC AS. 

10. SIP 200 (OK) response (SCC AS to I-CSCF) 

Since there is no update in the session description, no remote end update will be performed. The SCC AS sends 
confirmation response to the ATCF which contain the SDP answer that the SCC AS stored during the original 
session estabhshment procedure. 

11. SIP 200 (OK) response (I-CSCF to ATCF) 

12-13. SIP ACK request (ATCF to SCC AS via I-CSCF) 

14-17. SEP BYE request (SCC AS to UE A via I-CSCF, ATCF and P-CSCF) 

The SCC AS terminates the source access leg, which was using the old IP-CAN, by sending a SIP BYE request 
to the UE A. 

18-21. SIP 200 (OK) response (UE A to SCC AS via P-CSCF, ATCF and I-CSCF) 

Upon receiving the SIP BYE request over the old IP-CAN, the UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the UE A relinquishes all resources pertaining to the old IP-CAN. 
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Annex B (informative): 
Void 

Annex C (normative): 

Media feature tags defined within the current document 
C.1 General 

This subclause describes the media feature tag definitions that are applicable for the 3GPP IM CN Subsystem for the 
realisation of the MSG server assisted mid-call feature, Access Transfer Control Function, and SRVCC for calls in 
alerting phase. 



C.2 Definition of media feature tag g.Sgpp. mid-call 

Media feature-tag name: g.3gpp. mid-call 

ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 

Summary of the media feature indicated by this tag: This feature-tag when used in a SIP request or a SIP response 
indicates that the function sending the SIP message supports the MSC server assisted mid-call feature. 

Values appropriate for use with this feature-tag: none 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone supports the MSC server assisted mid-call feature 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 

C.3 Void 

C.4 Definition of media feature tag g.Sgpp.atcf 

Editor's note: [WID eSRVCC, CR#0353] this feature tag is to be registered with lANA after the draft-holmberg- 
sipcore-proxy-feature is adopted by IETF and after the freezing the Re 1-10 (whatever comes later) 

Editor's note: [WID eSRVCC, CR#0353] the insertion of the g.3gpp.atcf media feature tag is inline with the current 
solution in the draft-holmberg-sipcore-proxy-feature. The actual solution needs to align with the IETF 
accepted solution. 

Media feature-tag name: g.3gpp.atcf 

ASN.l Identifier: 1.3.6.1.8.2.x 
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Editor's note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 
Summary of the media feature indicated by this tag: 

This media feature tag when used in a Path header field as specified in IETF draft-holmberg-sipcore-proxy-feature [x] 
in SIP REGISTER request or SIP response to the SIP REGISTER request indicates that the resource identified by the 
URI in the Path header field supports the Access Transfer Control Function (ATCF). 

Values appropriate for use with this feature-tag: 

When used in a Path header field, the value follows the syntax as described in table C.4-1 for g-3gpp-atcf-in-path. 

Table C.4-1 : ABNF syntax of values of the g.Sgpp.atcf media feature tag 

g-3gpp-atcf -in-path = STN-SR 
STN-SR = addr-spec 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is used to indicate support of the ATCF. 

Examples of typical use: Indicating support of the ATCF. 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 

C.5 Definition of media feature tag g.Sgpp.srvcc-alerting 

Media feature-tag name: g.3gpp.srvcc-alerting 

ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 

Summary of the media feature indicated by this tag: This media feature-tag when used in a Contact header field of a SIP 
request or a SIP response indicates that the functional entity sending the SIP message supports SRVCC access transfer 
for calls in alerting phase, i.e. for calls whith early dialog. 

This media feature-tag when used in a Record-Route header field of a SIP request or a SIP response indicates: 

1 . that the functional entity sending the SIP message supports access transfer for calls in alerting phase; and 

2. all entitities of which the sender of the message is aware of being requested to support the feature do support 
access transfer for calls in alerting phase. 

Values appropriate for use with this feature-tag: none 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone supports SRVCC for calls in alerting phase. 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 
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Annex D (informative): 
XIVIL schemas 

D.1 IVISC server assisted mid-call feature XML schema 



D.1.1 General 

This subclause defines XML schema and MIME type related to the MSC server assisted mid-call feature. 



D.1.2 XML schema 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 
<xs : schema 

xmlns :xs = "http : //www. w3 . org/2 01/XMLSchema" 
elementFormDef ault= " qualified" 
attributeFormDef ault= " unqualified" > 

<xs:element name="mid-call" type= "Tmid-call " / > 

<xs : complexType name="Tmid-call" > 
<xs : sequence> 

<xs:element name= "participant " type= "xs : anyURI " minOccurs= " " maxOccurs= "unbounded" / > 
<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 

<xs : anyAttribute namespace= " ##any" processContents= " lax" / > 
</xs : complexType> 

</xs : schema> 

D.1 .3 lANA registration template 

Editor"s note: The MIME type "application/vnd.3gpp.mid-call+xml" as defined in this subclause is to be registered 
in the I/VNA registry for Application Media Types based upon the following template. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.mid-call+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21] 
Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations: 
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Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. 
Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 9.1.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

AppUcations which use this media: 

AppUcations support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 



D.2 state-and-event-info XML schema 



D.2.1 General 

This subclause defines XML schema and MIME type for session state and event information. It is used in the present 
document for SRVCC session transfer in alerting phase and for accepting of a call in alerting state transferred by the 
PS-PS access transfer procedures. 

D.2.2 XML schema 

<?xml version="l . 0" encoding="UTF-8"?> 

<xs : schema 

xmlns : xs = "http : //www . w3 . org/2 01/XMLSchema" 
element FormDefault= "qualified" 
attributeFormDef ault= "unqualified" > 



<xs : simpleType name= " directionType " > 
<xs : restriction base="xs : string" > 

<xs : enumeration value="initiator"/> 
<xs : enumeration value="receiver"/ > 
</xs : restriction> 
</xs : simpleType> 

<xs : element name= " state-and-event-info " type= "Tst ate -and- event- info" / > 

<xs : complexType name= "Tst ate -and- event- info " > 
<xs : sequence > 

<xs;element name= " state- info" type= "xs : string" minOccurs= " " maxOccurs= " 1 " /> 
<xs;element name="direction" type="directionType" minOccurs= " " maxOccurs= " 1 " /> 
<xs:element name="event" type= "xs : string" minOccurs= " " maxOccurs= " 1 " /> 
<xs:element name="anyExt" type= " anyExtType " minOccurs= " " /> 

<xs:any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 

<xs :anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs : complexType name= " anyExtType " > 
<xs : sequence> 

<xs:any namespace="##any" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
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</xs:schema> 

D.2.3 XML schema description 

This subclause describes the elements of the state-and-info XML Schema. 

<state-and-event-info>: The <state-and-event-info> element is used to indicate state and event information related 
to a specific dialog. In the present document, it is used to communicate information between the 
sec AS and the MSC-server for the purpose of SRVCC in the alerting state and for UE to 
communicate acceptance of incoming alerting state call transferred using PS -PS access transfer 
procedures. 

<state-info>: The <state-info> element is used to indicate the state of the dialog and is modelled on the FSM 
described in RFC 4235 [48]. In the present document, it can only have the values specified in 
table D.2.3- 1 for state-info- values. 

Table D.2.3-1 : ABNF syntax of values of the <state-info> element 

state- info-values = early-value 
early-value = %x65 . 61 . 72 . 6c . 79 ; "early" 



<direction>: The <direction> element indicates whether the observed user was the initiator of the dialog, or the 
recipient of the INVITE that created it. It can only have the values specified in table D.2.3-2 for 
direction-values. In the present document it must be included together with the <state-info> 
element. 

Table D.2.3-2: ABNF syntax of values of the <direction> element 

direction-values = initiator-value / receiver-value 
initiator-value = %x69 . 6e . 69 . 74 . 69 . 61 . 74 . 6f . 72 ; "initiator" 
receiver-value = %x72 . 65 . 63 . 65 . 69 . 76 . 65 . 72 ; "receiver" 



<event>: The <event> element is used to communicate an event that causes a dialog state transition. In the 

present document, the <event> element can only have the values specified in table D.2.3-3 for 
event-values. 

Table D.2.3-3: ABNF syntax of values of the <event> element 



event-values = call-accepted-value 

call-accepted-value = %x63 . 61 . 6c . 6c . 2d . 61 . 63 . 63 . 65 . 70 . 74 . 65 . 64 ; "call-accepted 



D.2.4 lANA registration template 

Editor"s note: The MIME type "application/vnd.3gpp.state-and-event-infoH-xml" as defined in this subclause is to be 
registered in the lANA registry for Application Media Types based upon the following template. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.state-and-event-infoH-xml 

Required parameters: 

None 

Optional parameters: 
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"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of apphcation/xml as specified in IETF RFC 3023 [21] 
Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. 
Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 10.0.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Apphcations which use this media: 

Applications support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 



D.3 SRVCC enhancement releated XML schema 



D.3.1 General 

This subclause defines XML schema and MIME type for transfer of information for SRVCC enhancement. 



D.3.2 XML schema 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 
<xs : schema 

xmlns :xs="http : //www . w3 . org/2 001/XMLSchema" 
elementFormDefault= "qualified" 
attributeFormDefault= "unqualified" > 

<xs : complexType name= " SRVCC- infoType " > 
<xs : sequence> 

<xs:element name= " ATU-STI " type= "xs : anyURI " minOccurs= " " / > 
<xs: element name= " C-MSISDN" type= "xs : anyURI " minOccurs= " " / > 
<xs: element name="anyExt" type="anyExtType" minOccurs="0"/> 

<xs : any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 

</xs : sequence> 

<xs : attribute name= " ATCF- Path-URI " type= "xs : anyURI " / > 
<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 
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<xs : complexType name= "SRVCC- inf osType" > 
<xs : sequence> 

<xs: element name=" SRVCC- info" type=" SRVCC- inf oType" 

minOccurs= " 1 " maxOccurs= "unbounded" / > 
<xs: element name= " anyExt " type="anyExtType" minOccurs= " " /> 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 

<xs : anyAttribute namespace= " ##any" processContents= " lax" / > 
</xs : complexType> 

<xs:element name= " SRVCC- inf os " type= " SRVCC- inf osType" / > 

<xs : complexType name="anyExtType" > 
<xs : sequence> 

<xs : any namespace= " ##any" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 
</xs : complexType> 

</xs : schema> 

D.3.3 Semantic 

Each <SRVCC-info> element contains SRVCC information related to one contact address (or registration flow, if 
multiple registration mechanism is used) of a UE with IM CN subsystem. The SRVCC information consists of: 

1) if the UE SRVCC Capability (see 3GPP TS 29.328 [6]) has value UE-SRVCC-CAP ABILITY-SUPPORTED 
and if the private user identity of the UE has associated STN-SR (see 3GPP TS 29.328 [6]): 

a) <ATU-STI> element containing the ATU-STI of the SCC AS; 

b) <C-MSISDN> element containing the Correlation MSISDN of the UE. 

NOTE: <ATU-STI> element and <C-MSISDN> element are not included if the UE SRVCC Capability (see 
3GPP TS 29.328 [6]) with value UE-SRVCC-CAP ABILITY-NOT-SUPPORTED. 

The "ATCF-Path-URI" attribute of the <SRVCC-info> element contains the ATCF URI for terminating calls of the 
registration (or registration flow, if multiple registration mechanism is used). 

<anyExt> element contains optional elements defined by future version of this document. 

Recipient of the XML ignores any unknown element and any unknown attribute. 



D.3.4 lANA registration template 

Editor"s note [eSRVCC, CR#0417]: The MIME type "application/vnd.3gpp.SRVCC-infoH-xml" as defined in this 
subclause is to be registered in the lANA registry for Application Media Types based upon the following 
template. The registration is to be started when work on the SRVCC WID completes. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.SRVCC-infoH-xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 
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Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21] 
Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. Any unknown XML 
elements and any unknown XML attributes are to be ignored by recipient of the MIME body. 

Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 10.2.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 
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Annex E (informative): 

INFO packages defined in the current document 

E.1 Info package for transfer of the conference 
information 

E.1.1 Scope 

This subclause contains the information required for the lANA registration of info package g.3gpp. mid-call in 
accordance with IETF RFC 6086 [54]. 

Editor"s note: MCC needs to register this info package with lANA when 24.237 9.6.0 is published. 

E.1 .2 g.Sgpp. mid-call info package 
E. 1 .2. 1 Overall description 

When PS to CS access transfer with the MSC Server assisted mid-call feature is applied for a session with conference 
focus there is a need to deliver participant identities from SCC AS to MSC server. 

E.1. 2.2 Applicability 

This package is used to transport participant identities when the PS to CS access transfer with the MSC server assisted 
mid-call feature is applied to a session with conference focus. 

E.1 .2.3 Info package name 

g.3gpp. mid-call 

E.1 .2.4 Info package parameters 

None defined 

E.1. 2.5 SIP options tags 

None defined 

E.1 .2.6 INFO message body parts 

The MIME type of the message body carrying participant identities is application/vnd.3gpp.mid-callH-xml. 
apphcation/vnd.3gpp.mid-callH-xml MIME type is defined in 3GPP TS 24.237. 

When associated with the g.3gpp.mid-call info package, the Content-Disposition value of the message body carrying 
participant identities is "info-package". 

E.1 .2.7 Info package usage restrictions 

None defined. 
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E.1 .2.8 Rate of INFO Requests 

Single INFO request generated after session set up. 

E.1 .2.9 Info package security considerations 

The security is based on the generic security mechanism provided for the underlying SIP signalhng. No additional 
security mechanism is defined. 

E.1. 2. 10 Implementation details and examples 

UAC generation of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; 
Stage 3" 

UAS processing of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; 
Stage 3" 

Examples: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

E.2 INFO package for transfer of state-and-event info 
E.2.1 Scope 

This annex defines an info package in accordance with IETF RFC 6086 [54] for sending state and event information 
during SRVCC access transfer using SIP INFO requests. 

E.2. 2 state-and-event info package 
E. 2.2.1 General 

This subclause contains the information required for the lANA registration of an info package. 
Editor"s note: MCC needs to register this info package with lANA after Rel-10 has been frozen. 

E.2. 2. 2 Overall description 

When SRVCC access transfer from PS to CS access is applied for a session with an active full duplex speech 
component and the related dialog is in early state there is a need to deliver state information from an SCC AS to an 
MSC server. Further it is requested that an MSC server supporting SRVCC access transfer for in alerting phase informs 
the SCC AS about a UE having accepted a terminating call. 

E. 2.2.3 Applicability 

This package is used to transport session state information and related event information when a session in alerting 
phase is transferred from PS to CS using SRVCC access transfer procedures. 

The mechanism allows that information about the session that is subject to SRVCC and related events to be sent inside 
an existing dialog due to the session transfer SIP INVITE request. 

E.2. 2. 4 Info package name 

The name of the info package is g.3gpp. state-and-event. 
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E. 2.2.5 Info package parameters 

No parameters are defined for the g.3gpp.state-and-event info package. 

E.2.2.6 SIP option tags 

No SIP option tags are defined for the g.3gpp.state-and-event info package. 

E.2.2.7 INFO message body parts 
E. 2.2. 7.1 General 

The state-and-event information is carried in the state-and-event-info message body, defined in annex D of 
3GPP TS 24.237. 

E.2.2.7.2MIMEtype 

The MIME type value for the message body is "application/vnd.3gpp.state-and-event-info+xnil", defined in annex D of 
3GPP TS 24.237. 

E.2.2.7. 3 Content disposition 

The Content Disposition value for the message body, when associated with the state-and-event info package, is "info- 
package" as defined in IETF RFC 6086 [54]. 

E.2.2.8 Info package usage restrictions 

No usage restrictions are defined for the state-and-event info package. 

E.2.2.9 Rate of INFO requests 

No maximum rate or minimum rate is defined for sending INFO requests associated with the state-and-event info 
package. 

When SRVCC in alerting phase is applied, then a single SIP INFO request is generated after the session transfer SIP 
INVITE request. This can be followed by one more additional SIP INFO request. 

E.2.2.10 Info package security considerations 

No additional security mechanism is defined for the state-and-event info package. 

The security of the state-and-event info package is based on the generic security mechanism provided for the 
underlaying SIP signalling. 

E. 2.2.1 1 Implementation details and examples 

See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 
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CP-090688 


0045 


1 


Changes to Overview 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0046 


1 


Change of Session Continuity to Access Transfer 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0047 


2 


Call flow for Controller UE releases Collaborative Session 


8.3.0 


9.0.0 


2009-09 


CT#45 


GP-090688 


0049 


3 


State Model for Collaborative Session handling 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0055 


3 


Clarification of SR VCC procedure 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090685 


0067 


6 


Call flow for UE initiating an emergency session in IMS using 
SRVCC 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090685 


0068 


6 


Call flow for EMC using SRVCC procedure 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0072 


1 


Clarification for the Service Control Signalling Path transfer for 
ICS session continuity during PS-PS transfer 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0089 


2 


Add indication of the capability of supporting mid-call feature 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0094 


2 


MSC Server assisted mid-call feature - SRVCC 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090685 


0106 


2 


E-SCC AS actions for IMS Emergency call 


8.3.0 


9.0.0 


2009-09 


CT#45 


CP-090688 


0109 


1 


MSC Server assisted mid-call feature - PS to CS 


8.3.0 


9.0.0 


2009-09 


CT#45 


GP-090688 


0111 


3 


MSC Server assisted mid-call feature - PS to PS 


8.3.0 


9.0.0 


2009-12 


CT#46 


CP-090929 


0048 


2 


Call flow for Remote party releases Collaborative Session 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0096 


3 


Signalling flow for Controller UE releases media flow on 
controller UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0097 


3 


Signalling flow for Controller UE releases media on Controllee 
UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0099 


3 


Signalling flow for Controllee UE modify media on itself 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0100 


6 


Signalling flow for Remote party adds new media on controllee 

UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0101 


3 


Signalling flow for Remote UE releases media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0110 


3 


MSC Server assisted mid-call feature - CS to PS - Altl 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0116 


4 


Roles for target UE discovery for Inter-UE Transfer 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0117 


5 


Roles of SCC AS for target UE discovery for Inter-UE Transfer 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0122 


1 


MSC Server assisted mid-call feature - flow updates - Altl 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0124 


1 


MSC Server assisted mid-call feature - capability exchange 
update 


9.0.0 


9.1.0 
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2009-12 


CT#46 


CP-090929 


0125 


1 


MSC Server assisted mid-call feature - PS to CS and SRVCC 
updates - Atll 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0128 


1 


MSC Server assisted mid-call feature - PS to PS updates 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0131 




sec UE not defined 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090927 


0132 




Renaming of E-SCC AS to EATF 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090927 


0133 


2 


E-SRVCC session origination 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090927 


0134 


2 


E-SRVCC access transfer 


9.0.0 


9.1.0 


2009-1 2 


CT#46 


CP-090929 


0136 


2 


Call flow for transferring a media to a controllee UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090928 


0146 


1 


Correction on PS-CS transfer information flow 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0149 


1 


MSC Server assisted mid-call feature - transaction identifiers 


9.0.0 


9.1 .0 


2009-12 


CT#46 


CP-09091 1 


0153 


1 


Enabling session continuity functionality 


9.0.0 


9.1 .0 


2009-1 2 


CT#46 


CP-090929 


0155 


2 


SC UE procedures for collaborative session establishment for 

transferring media 


9.0.0 


9.1.0 


2009-1 2 


CT#46 


CP-090929 


0156 


2 


SC UE procedures for collaborative session establishment with 

new media 


9.0.0 


9.1 .0 


2009-1 2 


CT#46 


CP-090929 


0157 


2 


sec AS procedures for collaborative session establishment for 

transferring media 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-09091 1 


0160 


1 


Address the Editor's Note in A. 3. 2 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-09091 1 


0162 


1 


Address the Editor's Note in A.8.2 


9.0.0 


9.1.0 


2009-1 2 


CT#46 


CP-090929 


0164 


2 


PS to CS transfer for speech and video session with MSC 
Server asisted mid-call feature 


9.0.0 


9.1 .0 


2009-1 2 


CT#46 


CP-090929 


0170 


2 


lUT Procedures 


9.0.0 


9.1.0 


2009-1 2 


CT#46 


CP-090929 


0171 


2 


Call flow for adding media to controllee UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-091047 


0173 


3 


SC AS procedures for collaborative session establishment with 
new media 


9.0.0 


9.1.0 


2009-1 2 


CT#46 


CP-090929 


0174 


3 


Procedures for releasing media on controllee UE by controller 

UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0175 


3 


Procedure for adding new media by remote party 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0176 


3 


Procedure for releasing media on ontroller UE by controller UE 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0177 


3 


Procedure for modifying media on contrllee UE by itself 


9.0.0 


9.1.0 


2009-12 


CT#46 


CP-090929 


0178 


2 


Signalling flow for Controllee UE releases media 


9.0.0 


9.1.0 


2010-03 


CT#47 


CP-100123 


0144 


5 


PS to CS or to (PS-i-CS) session transfer for an SC UE using Gm 
interface 


9.1.0 


9.2.0 


201 0-03 


CT#47 


CP-100143 


0182 


1 


Procedures for collaborative session release by controller UE 


9.1.0 


9.2.0 


201 0-03 


CT#47 


CP-100143 


0183 


1 


Procedures for controllee UE releases media component 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0184 


1 


Procedures for collaborative session release by remote party 


9.1.0 


9.2.0 


201 0-03 


CT#47 


CP-100143 


0185 


1 


Procedures for controller UE initiated media transfer from 
controller UE to controllee UE 


9.1 .0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0186 


1 


Establishment of collaborative session for inter-UE transfer 


9.1 .0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0187 


1 


Media adding/deleting within collaborative session for inter-UE 

transfer 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0188 


2 


Procedures for releasing media by remote UE 


9.1.0 


9.2.0 


?oio-m 


CT#47 




0189 


4 


r^nntrnllpr 1 IP initiatpH mpHia tranQfpr frnm pnntrnlipp 1 IF tn 

another controllee UE 


9.1 .0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0191 


2 


Procedures for controller UE initiated media transfer from 
controllee UE to another controllee UE 


9.1.0 


9.2.0 


201 0-03 


CT#47 


CP-100143 


0192 


3 


Procedures for controller UE initiated media transfer from 
controllee UE to another controllee UE — SCC AS behavior 


9.1 .0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0193 


-| 


Signalling flows for media transfer within collaborative session 
for inter-UE transfer 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0194 




Access tranter and MMTEL interaction 


9.1.0 


9.2.0 


201 0-03 


CT#47 


CP-100142 


0195 




Inter-UE transfer and MMTEL interaction 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0196 




Procedures for adding new media on controllee UE by controller 
UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0198 


1 


Release of collaborative session for inter-UE transfer 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0199 




Procedures for controllee UE releases media component 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0200 


■j- 


Procedures for collaborative session release by remote party 


9.1.0 


9.2.0 


201 0-03 


CT#47 


CP-100143 


0201 




Procedures for controller UE initiated media transfer from 
controller UE to controllee UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0202 




Adding new media on controllee UE by controller UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


GP-100143 


0203 




procedures for subscription to the session description 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0204 




SR VCC from MSC 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0206 




Deleting the editor note at A.15.3.2.2 for controller UE removing 
media at controllee UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0207 


1 


Deleting editor"s note for clause A.15.3.1 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0208 




Deleting the editor note at A.15.5 for controllee UE modify meida 

on itesif 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0209 




Complete session transfer routing clarification 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0210 




MSC Server assisted mid-call feature - single held session 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0211 




MSC Server assisted mid-call feature - flow clean up 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0212 




MSC server assisted mid-call feature - sendonly. recvonly 


9.1.0 


9.2.0 


2010-03 


CT#47 


GP-100142 


0213 




Incorrect reference correction 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0214 




Removal of ICMP message sending - procedures 


9.1.0 


9.2.0 
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2010-03 


CT#47 


CP-100143 


0217 


1 


Registration requirements for an SC UE tliat oniy impiements 
IntGr-UE Transfer 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0218 


2 


Addition of the Content-Type to SiPfrag containing SDP 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0219 


3 


Separating releasing media on controllee UE and removing 
controllee UE from collaborative session 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0220 




Correction of Procedures for adding new media by remote party 
when the controller UE does not alert the user 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0221 


1 


Removal of Editor's Note on use of SDP in URI parameters in 
Refer-To header 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0223 


1 


Editorial changes to clause 8 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0224 


1 


Editorial changes to clause 9 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0225 


1 


Editorial changes to clause 14 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0226 




Editorial changes to clause 16 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0227 




Editorial changes to clause 19 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0228 


Y- 


Editorial changes to clause A.I 2.3 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0229 


1 


Editorial changes to clause A. 13.2 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0230 


1 


Editorial changes to clause A. 14 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0232 




Editorial changes to clause A.I 6 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0233 




Editorial changes to clause C.2 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100123 


0236 




Clarification of SC OMA MO use 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-1 00240 


0237 




Removal of IMS communication service from emergency call 

flows 


9.1.0 


9.2.0 


201 0-03 


CT#47 


CP-100135 


0238 




SR VCC abnormal case 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100123 


0240 




Correct the definition of Correlation MSISDN 


9.1.0 


9.2.0 


201 0-03 


CT#47 


CP-100143 


0241 


2 


Controller UE initiated media transfer from controllee UE to 
another controllee UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0242 




UE remote changed to Remote UE 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0243 


1 


Merged corrections to A.15.3.2.1, A.15.3.2.2 agreed at the 
CTIe-meeting 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-1 001 40 


0244 




EATF editor's notes resolution 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0245 




EN on SIP URI of SCC AS 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0246 


2 


Collaborative session establishement of with new media 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0247 


1 


SCC AS procedures for collaborative session establishment with 
new media 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100142 


0248 


4 


Addition of media feature tag for indicating lUT Controller 

capability 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-1 001 41 


0249 




Editorial changes to clause 4 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0250 




Editorial changes to clause 6 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0251 




Editorial changes to clause 7 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0252 


2 


Editorial changes to clause 10 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0253 


1 


Editorial changes to clause 1 1 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0254 




Editorial changes to clause 12 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0255 




Editorial changes to clause 13 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0256 


1 


Editorial changes to clause A.3 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0257 


1 


Editorial changes to clause A. 6 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0258 




Editorial changes to clause A. 7 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0259 




Editorial changes to clause A.8 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0260 




Editorial changes to clause A.9 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0261 




Editorial changes to clause A.1 1 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0262 




Editorial changes to clause A. 16 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-1 001 40 


0263 


1 


Editorial changes to clause A. 17 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100141 


0264 




Inappropriate normative language in relation to registration 


9.1.0 


9.2.0 


2010-03 


CT#47 


CP-100143 


0197 


1 


Remove of signaling flow for target UE discovery 


9.1.0 


9.2.0 


2010-03 


CT#47 








Editorial cleanup by MCC 


9.1.0 


9.2.0 


2010-06 


CT#48 


CP-1 00359 


0130 


1 


MSG Server assisted mid-call feature - conferencing 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0265 




Removal of editorial notes 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0266 




Controllee UE announces controller capabilities 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0268 


1 


Editorial corrections 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0275 




Correction of references 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0276 


— 


Removing controllee UE procedure correction 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0279 




Compliance corrections 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0280 




PS-CS access transfer corrections 


9.2.0 


9.3.0 


201 0-06 


CT#48 


CP-1 00359 


0282 


— 


PS to CS+PS access transfer corrections 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0283 




SRVCC corrections 


9.2.0 


9.3.0 


201 0-06 


CT#48 


CP-1 00359 


0284 




Race condition during SRVCC 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0285 




MSC Server assisted mid-call feature and SR VCC abnormal 

case 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0286 




Inter UE Transfer corrections - procedure overlap 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0287 


2 


Inter UE Transfer corrections - collaborative session by media 

transfer 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0288 


2 


Inter UE Transfer corrections - collaborative session by media 
transfer 


9.2.0 


9.3.0 
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2010-06 


CT#48 


CP-1 00359 


0289 




Inter UE Transfer corrections - session discovery corrections 


9.2.0 


9.3.0 


201 0-06 


CT#48 


CP-1 00359 


0290 


1 


Inter UE Transfer corrections - media transfer during col. session 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0291 


1 


Inter UE Transfer corrections - media adding/deleting during col. 

session 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0292 


2 


Correction of Referred-By header usage 


9.2.0 


9.3.0 


2010-06 


CT#48 


CP-1 00359 


0293 


1 


Correction of iut-controller feature tag usage 


9.2.0 


9.3.0 


2010-09 


CT#49 


CP-1 00505 


0298 




Editorial Corrections 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0299 




Removing unnecessary condition for sending SIP UPDATE or 
SIP re-INVITE request 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00493 


0307 


2 


Clarifying SC UE procedures for terminations 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0308 


1 


Inform remote end about new local end 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00493 


0310 


3 


Corrections use of 3GPP TS 24.216 MO leaf 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0314 


3 


Modification of SCC AS procedure in MSC server assisted mid- 
call feature 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0315 


2 


lUT Cleanup 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00493 


0319 


1 


UE compliance 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00493 


0327 


1 


IVIodification the usage for instance ID in session transfer 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00505 


0328 


2 


Clarification of MSC server apply ICS capability 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 0051 9 


0316 


1 


Insertion of missing requirement to prohibit PS-CS continuity 


9.4.0 


10.0.0 


201 0-09 


CT#49 


CP-1 0051 9 


0321 


1 


Error correction and modify signalling flows for controller UE 
initiated media transfer from controller UE to controllee UE 


9.4.0 


10.0.0 


201 0-09 


CT#49 


CP-1 0051 9 
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Flow for SRVCC in alerting state - terminating case 
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Flow for SRVCC in alerting state - originating case 
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Mid-call scenairos for incoming and outgoing call in alerting state 
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Call flow for transfering an incoming waiting call in alerting phase 
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Signalling flows for PS-CS access transfer when using ATCF 
enhancements and without media anchored 
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Signalling flows for PS-CS access transfer when using ATCF 
enhancements and media anchored 
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Corrections of SC UE registaration 
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ICS UE prevented from Gm control adding when ICS is disabled 
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SRVCC enhancements - registration flow 
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SRVCC enhancements - originating session set up flow 
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SRVCC enhancements - ATCF registration procedures 
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SRVCC enhancements - scope, definition, compliance 
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Correction in SRVCC Emergency Flows. 
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Flows for SRVCC in alerting state - Race condition when 
answering in PS 
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SCC AS procedures for SRVCC alerting state 
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MSC server procedure for SRVCC in alerting 
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Definition of INFO package for SRVCC alerting 
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Further flow for SRVCC in alerting state race condition when 
answering in PS 


10.0.0 


10.1 .0 


2010-12 


CT#50 


CP-1 00863 


0368 


2 


UE and SCC AS procedures for abnormal cases of SRVCC 
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SC UE procedures for SRVCC in Alerting Phase 
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SCC AS procedure for PS to CS Access Transfer: SRVCC 

enhancements using ATCF 
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Correction of the SCC AS association procedure 
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SRVCC enhancements - ATCF invocation 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00746 


0335 


1 


Editor"s note deleting for remote UE releases media on the 
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SRVCC clarifications for SDP offer by the MSC. 
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PS-PS access transfer in early dialog state 
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Remote leg release 
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Contact registration 
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Editor's note delete for aSRVCC on A. 17.1 
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Adding clauce A.I 8 for eSRVCC signalling flow 
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Reference update: RFC 6086 
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STN-SR missing in procedures 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 101 99 


0395 


2 


Tl assignment for MSC server for srvcc for alerting call 
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Alerting SRVCC when another call exists 
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SRVCC enhancement, ATCF access transfer procedures 
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SRVCC enhancement, ATCF compliance update 
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Format and triggers for SCC AS sending ATU-STI and C- 
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SRVCC enhancement, ATCF call set up procedures 
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Corrections of UE procedures for SRVCC in alerting state 
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Clarification of MSC server procedures. 
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PS-PS transfer corrections 
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Active media component 
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Transport of ATU-STI and C-MSISDN from SCC AS to ATCF 
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SRVCC enhancement, ATCF procedures when no active call 
exists 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10198 


0435 


2 


SRVCC enhancements, SCC AS procedure 
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Indicating support for SRVCC alerting state 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10198 


0453 




Referencing 3GPP TS 23.003 for identity definitions 
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Adding call flow for incoming call in alerting phase with forked 
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Shifting Rel-9 lUT material OUT of TS 24.237 
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